On Monday, August 06, 2001 11:18:26 PM +0200 Daniel Phillips
>> Grin, we're talking in circles. My point is that by having two
>> threads, bdflush is allowed to skip over older buffers in favor of
>> younger ones because somebody else is responsible for writing the
>> older ones out.
> Yes, and you can't imagine an algorithm that could do that with *one*
Imagine one? Yes. We're mixing a bunch of issues, so I'll list the 3
different cases again. memory pressure, write throttling, age limiting.
Pretending that a single thread could get enough context information about
which of the 3 (perhaps more than one) it is currently facing, it can make
the right decisions.
The problem with that right now is that a single thread can't keep up (with
one case, let alone all 3) as the number of devices increases. We can more
or less just replay the entire l-k discussion(s) on threading models here.
In my mind, in order for a single thread to get the job done, it can't end
up waiting on a device while there are still buffers ready for writeout to
As for a generic mechanism to schedule all FS writeback, I've been trying
to use writepage ;-) The bad part here it makes the async issues even
bigger, since the flushing thread ends up calling into the FS (who knows
what that might lead to).
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Aug 07 2001 - 21:00:45 EST