On Wed, 27 Jan 1999 20:11:02 +0100 (CET), Andrea Arcangeli
<andrea@e-mind.com> said:
> Stephen the problem is that currently when we write to a block device we
> only:
> 1. get the buffer uptodate
> 2. write to the buffer the new data in the right place
> 3. mark the buffer dirty and uptodate
> 4. release the buffer
> but we don't start I/O at all, so in a msec we'll be in a state with
> 128mbyte full of dirty and so not freeable buffers.
No. When we release the buffer we call refile_buffer to put it on the
dirty list, and that does a wakeup_bdflush once the number of dirty
buffers exceeds (nr_buffers * bdf_prm.b_un.nfract/100).
The real problem is that we don't ever wait for that IO to complete, and
that _is_ a real problem: it allows the dirty buffers to accumulate
uncontrollably. We do start IO, but we don't slow down the growth of
the buffer cache. For now we do
if (nr_buffers_type[BUF_DIRTY] > too_many)
wakeup_bdflush(0);
where the parameter to wakeup_bdflush() tells us whether or not to wait
for the bdflush pass to complete. We probably need something like
if (nr_buffers_type[BUF_DIRTY] > 3 * too_many)
wakeup_bdflush(1);
else if (nr_buffers_type[BUF_DIRTY] > too_many)
wakeup_bdflush(0);
In other words, if the number of dirty buffers grows too excessive, then
we kick of a round of bdflush _and_ wait for the IO to complete,
stalling the generation of new dirty buffers until we have flushed at
least one round of IO (by default that means writing 500 buffers).
I'm going to try out combinations of the above on large and small
machines to make sure we get something which doesn't impact normal
performance too badly, but I suspect that a simple change like the above
in refile_buffer will be enough to cure the complete memory anihilating
behaviour of the new, lean buffer cache code.
--Stephen
-
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/