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
next prev parent 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®