[...]
With an IDE drive I saw a 600% performance improvement on one
(admittedly contrived benchmark). I'm using an IDE rather than my SCSI
disk since I don't have any way to control the write caching on my SCSI
drive.
I have similar patches I was playing with from 2.1.26 and also saw a massive
improvement with IDE drives (although not at high at 600%) but was unable to
get any major improvements with SCSI drives.
When I originally did this I also implemented a character device which was
used to read the order writes per performed during the last bdflush, and
using awk scripts was able to determine how many times the 'head' would have
to change direction. (This being dependent on the drives physical geometry).
With a reasonable amount of RAM (128MB) its quite surprising just how much
unnecessary disk activity there is because of this.
Presumably the same situation may also exist when reading, but I'm not
really sure how this can be improved... (I did think of creating a global
request queue, and when >= n tasks are waiting or before m ticks, re-order
and perform the reads? Doesn't sound very good to me).
The other major concern I had was that if I had many many buffers to flush
(say over 100MB) that the sort would take a non-trivial amount of time and
actually worsen the situation. I actually wrote use-land code to test this
idea by dumping the write-list from the previous bdflush and timing various
sorts.... could this be an issue for machines with large amounts of buffers?
(Assume worst case time to sort 30,000 elements?) There was also an issue of
additional memory required to do all this, but that I'm sure can probably be
worked around.
I also used a quick-sort... which obviously is evil because of the large
amount of stack required. I think changing to a shell-sort is where I gave
up because I couldn't get the sort to work <g>
in the end I managed to side-step the issue my moving to DPT 3224 SCSI
controller with hardware striping. Way kewl setup, unfortunately grossly
overpriced.
-cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu