Messages in this thread | | | From | Heinz Mauelshagen <> | Subject | Re: Linux-2.2.0 bad VM behaviour "dd if=/dev/zero of=/dev/hdc bs=256k" | Date | Fri, 05 Feb 1999 1:53:30 MET |
| |
<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/
| |