Re: Patch for block write clustering

Rik van Riel (
Wed, 4 Mar 1998 21:56:10 +0100 (MET)

On Thu, 5 Mar 1998, Chris Wedgwood wrote:

> 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.

| For Linux mm-patches, go to | "I'm busy managing memory.." |
| my homepage (via LinuxHQ). | |
| ...submissions welcome... | |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to