>> 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*
> thread?
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
idle devices.
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).
-chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/