On Thu, 4 Feb 1999 14:44:13 GMT, "Stephen C. Tweedie" <sct@redhat.com> wrote:
> 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, i did a quick test to get a result in refile_buffer():
if (nr_buffers_type[BUF_DIRTY] > too_many)
wakeup_bdflush(1);
^^^
It works great but may be to aggressive.
I get the same timing for a "mke2fs /dev/v/l" of a 13GB LVM device
filling up nearly all free memory (256MB RAM system)
as i do, if i put in a buffermem limiting hack and limit the
buffer cache to 20MB (your dirty/clean list patch with both included!).
Same positive test result with "dd if=/dev/zero of=/dev/v/l bs=256k"
Good interactive performance under X while test is eating up memory.
For eg.: - pop up of xterm after 2-3 seconds (not in cache); 0.xs in cache 8*)
- cursor pretty responsive
- netscape starup in about 4-5s
- no swapping
Heinz
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement C/S Deutsche Telekom AG Entwicklungszentrum Darmstadt Heinz Mauelshagen Otto-Roehm-Strasse 71c Senior Systems Engineer Postfach 10 05 41 64205 Darmstadt mge@ez-darmstadt.telekom.de Germany +49 6151 886-425 FAX-386 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- 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/