> And peppering code with cute little comments + feeding patches to Rusty's
> 'trivial' patchbot.
>
> BTW, are units consistent? Kilobytes? Pages? Sectors?
No. Here's a sample (2.2 kernel):
disk 25418854 0 0 0 <--- total "operations" = calls to a routine whose
name I've forgotten
disk_rio 6950521 0 0 0 <--- total reads = read calls to the routine
disk_wio 18468333 0 0 0 <--- total writes = write calls to the routine
disk_rblk 14410934 0 0 0 <--- total 512 byte "blocks" read
disk_wblk 37146264 0 0 0 <--- total 512 byte "blocks" written
page 30108037 50709997 <--- number of 1024 byte "pages" read and written
-- counted in another routine whose name I've forgotten
swap 532282 341062 <--- number of PAGESIZE chunks read and written to
swap space -- counted in yet another routine whose name I've forgotten.
The routine names are listed in a thread a few weeks back where I first
got these discoveries from someone who presumably had been down this
path before. I don't have a 2.4 kernel sample handy; the "disk" entries
changed to a bizarre format that required a whole new parser in my code
and some complicated logic to figure out whether it was dealing with 2.2
or 2.4 :(.
As you can probably guess, this sort of thing is one of the issues that
my "COUGAR" proposal corrects. I leave design issues to the designers,
but one thing I insist on is that there *be* requirements --
*documented* requirements -- and a *documented* and debated design
*before* hacking the code into the kernel and making implementation
decisions.
Of course, since I would be the designer of at least part of "COUGAR", I
would be making some of those decisions. Unfortunately, I have limited
time to work on "COUGAR" until maybe late July, so if someone wants to
pick up some of the balls and run with them, I'm willing to unload them.
(Apologies if my metaphor jars those of you who live where football is
played without the use of hands :).
This is a process I highly recommend for performance-determining parts
of Linux, like memory management and the scheduler. I know the memory
management and scheduler gurus -- Rik, Andrea, Ingo and others -- *have*
designs in their heads, *have* requirements that they're working to -- I
just think we should be sharing and debating *those* on the list instead
of just code and benchmark results.
-- M. Edward Borasky znmeb@borasky-research.netThe COUGAR Project http://www.borasky-research.com/Cougar.htm
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/