> 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.
>
> Except for the part about a 1 buffer minimum -- otherwise a slow device
I just wanted to say than we could flush more than 1 buffer from a dirty
sub-list at a time in our heuristic and that 1 was indeed the minimum:) .
> will still be able to throttle the system once its queue is full.
If one device is full, but other devices have some IOs to do, it is still
a win, and obviously, if we flush too much things we will have to wait at
some moment.
> > But why would we ever want to use an LRU list for write-outs?
> > 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...
>
> Yes and no: think of temporary files or even the bitmaps on a busy
> filesystem. If you order requests before doing LRU on them, these will
> get flushed out to disk much more frequently than need under normal
> circumstances. It'll be nice once we have a filesystem that does safe
> metadata ordering...
The order is indeed important, but I often read posts where coalescing is
not considered as important. In my opinion, coalescing is at least as
important under Linux and probably far more important with modern SCSI
disks.
Since Linux is most of the time doing 1 thing (page/block) logical IO at a
time from upper kernel layers, the ordering is just the friend of the
coalescing algorithm, but the ordering consumes CPU when queues are larges
(n**2) and most applications use to provide data in some not random order.
This let me think that if it was possible to coalesce IOs at the source
and just not to try to order too much, perhaps the overal results
(compromise between CPU and IO performance) would be better using modern
SCSI disks. It is just some guessing and frankly I am actually not sure to
be right or just wrong. :-) And btw, for usual applications that write
large sequential part of files at a time, the IOs are probably not that
misordered in the LRU and we probably would want to avoid the N**2 cost of
the sort in this situation.
Regards,
Gerard.
-
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/