> 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.
OK, so we really need somethink like this to go into the kernel.
> 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).
Under Solaris, reading/writing (at least to swap) is done by
a kernel thread. When we do that, it becomes way easier to
program all sorts of complex sorting algoritms, but I wonder
whether that would be worth it...
> 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
You could do the sorting at the moment the buffer is inserted.
When you divide the list in (say) 8 or 16 lists, it would be
quite feasable to insert each buffer at the right place.
> in the end I managed to side-step the issue my moving to DPT 3224 SCSI
> controller with hardware striping.
If the DPT can do it (with far less overhead), we should be
able to make Linux do it.
Rik.
+-----------------------------+------------------------------+
| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | H.H.vanRiel@fys.ruu.nl |
| ...submissions welcome... | http://www.fys.ruu.nl/~riel/ |
+-----------------------------+------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu