> On Mon, 29 Mar 1999, Gerard Roudier wrote:
>
> > By flushing part of each dirty list at a time (minimum 1 buffer),
> > and circularily scanning these dirty lists, bdflush will have far
> > more chance to feed several devices, before having to wait, than
> > using a single dirty list.
>
> This seems like a winning idea to me.
Thanks.
> > Basically, for SCSI disks, using for example 8 dirty lru lists and
> > the following hash: [SNIP]
>
> But why would we ever want to use an LRU list for write-outs?
Because we are unable to ask applications about buffers that will be
rewritten soon and those that will not. ;-)
The LRU is just some minimal and simple aging heuristic that can be used
when we have no other info about the relevance of caching or not. It is
usually better that just random and fairly simple.
> It would be much better to sort the buffers in the order they're
> occupying on the disk, that'll give the lower layers a better
> chance of doing some I/O clustering and will reduce search times,
> improve throughput, etc...
Indeed. Doing sort/coalesce in a layer that knows of everything to write
allows to do a better work that in a layer that has only partial
informations, but this may need some large redesign of the current buffer
code, at least.
Most applications are writing data in large chunks or quickly write
sequentially blocks. When a disk in not too fragmented, sequential writes
to a file are mostly sequential data to the disk and so, blocks have
chance to be fairly ordered in the LRU. For this reason the LRU is
probably not bad for lower layers to be provided with coalescable and not
to misordered blocks to write.
My concern was to suggest some change that could be candidate for 2.2
and/or 2.0, thus quite simple. Your suggestions are indeed interesting and
could be inverstigated for 2.3/2.4 development, in my opinion.
> We can always free the clean buffers in LRU order later on.
Thanks for your interesting reply, Rick.
Regards,
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/