Messages in this thread | | | Date | Tue, 30 Mar 1999 21:16:30 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: IDEA: multiple dirty lists in buffer.c |
| |
On Tue, 30 Mar 1999, Rik van Riel wrote:
> 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/
| |