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

> 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).

Hmm...Good idea! I was going to suggest something like this after seeing
that streaming out large amounts of data to a file ended up toasting all
toastable memory pages on the system.

I'm confused as to how this actually works, though...

Above, in buffer.c:

int too_many = (nr_buffers * bdf_prm.b_un.nfract/100);

Meaning that too_many is set to the percentage of all buffers currently
allocated (defaults to 40%, correct?).

Your proposed change:

> if (nr_buffers_type[BUF_DIRTY] > 3 * too_many)

Would check to see if the dirty buffer list has more buffers than three
times the number of too_many, which is already 40% of the total (?).
Isn't this going to be an impossible case, as the condition in the default
case would be checking for there being over 120% of the buffers dirty?

I'm pretty sure I'm missing something, but I can't see anything obvious.

Simon-

| Simon Kirby | Systems Administration |
| mailto:sim@netnation.com | NetNation Communications |
| http://www.netnation.com/ | Tech: (604) 684-6892 |


-
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.069 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site