mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Wilck <martin.wilck@fujitsu-siemens.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC for 2.6: avoid OOM at bounce buffer storm
Date: Wed, 08 Jun 2005 20:54:16 +0200	[thread overview]
Message-ID: <42A73ED8.9040505@fujitsu-siemens.com> (raw)
In-Reply-To: <20050607120811.6527a9ff.akpm@osdl.org>

Hello Andrew,

> The semaphore is initialised with the limit level, so once it has been
> down()ed more than `limit' times, processes will block until someone does
> up().

Oh - of course. Neat.

>>It appears to run much more 
>> smoothly now, perhaps because wakeup_bdflush() isn't called any more. 
>> Are you still interested in more data?
> 
> Perhaps the newer kernel has writeback thresholding fixes so it's not
> possible to dirty as much memory with write().

I have collected more data and the behavior with 2.6.12-rc5-mm2 is 
flawless, there is a continuous writeback flow close to the maximum rate 
possible, and the bounce buffer usage never gets anywhere near the limit 
where it'd become dangerous. At least not in my test setup. The latest 
fedora kernel 2.6.11-1.27 also behaves ok, although it doesn't adapt to 
changing io load as smoothly as 2.6.12-rc5-mm2 does, and the writeback 
rate is oscillating more strongly.

The kernels where I observe the problem are 2.6.9 kernels from RedHat 
EL4. I have posted this here because I saw that the highmem bounce 
buffer/memory pool implementation was identical between the 2.6.9 kernel 
and all but the very latest development kernels, and I concluded 
prematurely that the behavior under my scenario must also be the same -- 
which it wasn't. I apologize for not having looked more closely.

Many thanks for looking into this anyway. From a theoretical point of 
view, I still think I had a valid point :-/.

Your patch sure looks good to me.

Regards
Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy

  reply	other threads:[~2005-06-08 18:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-03 15:47 Martin Wilck
2005-06-03 23:06 ` Andrew Morton
2005-06-07 14:20   ` Martin Wilck
2005-06-07 19:08     ` Andrew Morton
2005-06-08 18:54       ` Martin Wilck [this message]
2005-06-08 21:46         ` Andrew Morton
2005-06-14 16:22           ` Martin Wilck
2005-06-14 20:38             ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42A73ED8.9040505@fujitsu-siemens.com \
    --to=martin.wilck@fujitsu-siemens.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®