From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Christoph Lameter <clameter@sgi.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hugh@veritas.com>,
James Bottomley <James.Bottomley@HansenPartnership.com>,
Andrew Morton <akpm@linux-foundation.org>,
FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
Jens Axboe <jens.axboe@oracle.com>,
"Rafael J. Wysocki" <rjw@sisk.pl>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] scsi: fix sense_slab/bio swapping livelock
Date: Tue, 08 Apr 2008 23:40:07 +0200 [thread overview]
Message-ID: <1207690807.29991.50.camel@lappy> (raw)
In-Reply-To: <47FBDF9E.90102@cs.helsinki.fi>
On Wed, 2008-04-09 at 00:11 +0300, Pekka Enberg wrote:
> Christoph Lameter wrote:
> > Hmmmm... Peter has the most experience with these issues. Maybe the best
> > would be to have this sort of logic in a more general way in the page
> > allocator? Similar issues surely exist with the page allocator and a fix
> > there would fix it for all users.
>
> This needs some support in the slab allocator anyway. Keep in mind that
> the patch is specifically addressing writeback in OOM conditions so we
> must (1) prioritize GFP_TEMPORARY allocations over everyone else (which
> just get NULL) and (2) use the remaining available memory as efficiently
> as possible for _all_ GFP_TEMPORARY allocations.
>
> Peter is, however, bringing up a good point that my patch doesn't
> actually _guarantee_ anything so I'm still wondering if this approach
> makes any sense... But I sure do like Linus' ideas of marking
> short-lived allocations and trying harder for them in OOM.
Also, this scheme so far does not provide for a means to detect the end
of pressure situation.
I need both triggers, enter pressure and exit pressure. Enter pressure
is easy enough, that's when normal allocations start failing. Exit
pressure however is more difficult - that is basically when allocations
start succeeding again. You'll see that my patches basically always
attempt a regular allocation as long as we're in the emergency state.
Also, the requirement for usage of emergency memory (GFP_MEMALLOC,
PF_MEMALLOC) is that it will be freed without external conditions. So
while it might be delayed for a while (it might sit in the fragment
assembly cache for a while) it doesn't need any external input to get
freed again:
- it will either get reclaimed from this cache;
- it will exit the cache as a full packet and:
- get dropped, or
- get processed.
next prev parent reply other threads:[~2008-04-08 21:41 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-06 22:56 [PATCH] scsi: fix sense_slab/bio swapping livelock Hugh Dickins
2008-04-06 23:35 ` James Bottomley
2008-04-07 1:01 ` Hugh Dickins
2008-04-07 17:51 ` Hugh Dickins
2008-04-07 18:04 ` James Bottomley
2008-04-07 18:26 ` Hugh Dickins
2008-04-07 2:48 ` FUJITA Tomonori
2008-04-07 18:07 ` Hugh Dickins
2008-04-08 14:04 ` FUJITA Tomonori
2008-04-07 5:26 ` Christoph Lameter
2008-04-07 19:40 ` Hugh Dickins
2008-04-07 19:55 ` Peter Zijlstra
2008-04-07 20:31 ` Hugh Dickins
2008-04-07 20:47 ` Peter Zijlstra
2008-04-07 21:00 ` Pekka Enberg
2008-04-07 21:05 ` Pekka Enberg
2008-04-07 21:15 ` Linus Torvalds
2008-04-07 21:34 ` Pekka Enberg
2008-04-07 21:39 ` Pekka Enberg
2008-04-07 22:05 ` Pekka J Enberg
2008-04-07 22:17 ` Linus Torvalds
2008-04-07 22:42 ` Pekka Enberg
2008-04-08 20:42 ` Pekka J Enberg
2008-04-08 20:44 ` Pekka Enberg
2008-04-08 20:45 ` Christoph Lameter
2008-04-08 21:11 ` Pekka Enberg
2008-04-08 21:40 ` Peter Zijlstra [this message]
2008-04-07 21:30 ` Hugh Dickins
2008-04-07 21:36 ` Pekka Enberg
2008-04-08 20:43 ` Christoph Lameter
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=1207690807.29991.50.camel@lappy \
--to=a.p.zijlstra@chello.nl \
--cc=James.Bottomley@HansenPartnership.com \
--cc=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=hugh@veritas.com \
--cc=jens.axboe@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@cs.helsinki.fi \
--cc=rjw@sisk.pl \
--cc=torvalds@linux-foundation.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