lkml.org 
[lkml]   [1999]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Linux-2.2.0 bad VM behaviour "dd if=/dev/zero of=/dev/hdc bs=256k"
Date


<SNIP>

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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.054 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site