All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks
Date: Thu, 23 Aug 2007 14:59:48 +0200	[thread overview]
Message-ID: <1187873988.6114.388.camel@twins> (raw)
In-Reply-To: <20070823120819.GO13915@v2.random>

On Thu, 2007-08-23 at 14:08 +0200, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2007 at 12:09:03AM +0200, Peter Zijlstra wrote:
> > Strictly speaking:
> > 
> > if:
> > 
> >  page = alloc_page(gfp);
> > 
> > fails but:
> > 
> >  obj = kmem_cache_alloc(s, gfp);
> > 
> > succeeds then its a bug.
> 
> Why? this is like saying that if alloc_pages(order=1) fails but
> alloc_pages(order=0) succeeds then it's a bug. Obviously it's not a
> bug.
> 
> The only bug is if slab allocations <=4k fails despite
> alloc_pages(order=0) would succeed.

That would be currently true. However I need it to be stricter.

I'm wanting to do networked swap. And in order to be able to receive
writeout completions when in the PF_MEMALLOC region I need to introduce
a new network state. This is because it needs to operate in a steady
state with limited (bounded) memory use.

Normal network either consumes memory, or fails to receive anything at
all.

So this new network state will allocate space for a packet, receive the
packet from the NIC, inspect the packet, and toss the packet when its
not found to be aimed at the VM (ie. does not contain a writeout
completion).

So the total memory consumption of this state is 0 - it always frees
what it takes, but the memory use is non 0 but bounded - it does
temporarily use memory, but will limit itself to never exceed a given
maximum)

Because the network stack runs on the slab allocator in generic (both
kmem_cache and kmalloc) I need this extra guarantee so that a slab
allocated from the reserves will not serve objects to some random
non-critical application.

If this is not restricted this network state can leak memory to outside
of PF_MEMALLOC and will not be stable.

So what I need is:

  kmem_cache_alloc(s, gfp) to fail when alloc_page(gfp) fails

agreeing on the extra condition:

  when kmem_cache_size(s) <= PAGE_SIZE

and the extra note that:

  I only really need it to fail for ALLOC_NO_WATERMARKS, the other
  levels like ALLOC_HIGH and ALLOC_HARDER are not critical.

Which ends up with:

  if the current gfp-context does not allow ALLOC_NO_WATERMARKS
allocations, and alloc_page() fails, so must kmem_cache_alloc(s,) if
kmem_cache_size(s) <= PAGE_SIZE.

(yes this leaves jumbo frames broken)


WARNING: multiple messages have this Message-ID (diff)
From: Peter Zijlstra <peterz@infradead.org>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC 0/7] Postphone reclaim laundry to write at high water marks
Date: Thu, 23 Aug 2007 14:59:48 +0200	[thread overview]
Message-ID: <1187873988.6114.388.camel@twins> (raw)
In-Reply-To: <20070823120819.GO13915@v2.random>

On Thu, 2007-08-23 at 14:08 +0200, Andrea Arcangeli wrote:
> On Wed, Aug 22, 2007 at 12:09:03AM +0200, Peter Zijlstra wrote:
> > Strictly speaking:
> > 
> > if:
> > 
> >  page = alloc_page(gfp);
> > 
> > fails but:
> > 
> >  obj = kmem_cache_alloc(s, gfp);
> > 
> > succeeds then its a bug.
> 
> Why? this is like saying that if alloc_pages(order=1) fails but
> alloc_pages(order=0) succeeds then it's a bug. Obviously it's not a
> bug.
> 
> The only bug is if slab allocations <=4k fails despite
> alloc_pages(order=0) would succeed.

That would be currently true. However I need it to be stricter.

I'm wanting to do networked swap. And in order to be able to receive
writeout completions when in the PF_MEMALLOC region I need to introduce
a new network state. This is because it needs to operate in a steady
state with limited (bounded) memory use.

Normal network either consumes memory, or fails to receive anything at
all.

So this new network state will allocate space for a packet, receive the
packet from the NIC, inspect the packet, and toss the packet when its
not found to be aimed at the VM (ie. does not contain a writeout
completion).

So the total memory consumption of this state is 0 - it always frees
what it takes, but the memory use is non 0 but bounded - it does
temporarily use memory, but will limit itself to never exceed a given
maximum)

Because the network stack runs on the slab allocator in generic (both
kmem_cache and kmalloc) I need this extra guarantee so that a slab
allocated from the reserves will not serve objects to some random
non-critical application.

If this is not restricted this network state can leak memory to outside
of PF_MEMALLOC and will not be stable.

So what I need is:

  kmem_cache_alloc(s, gfp) to fail when alloc_page(gfp) fails

agreeing on the extra condition:

  when kmem_cache_size(s) <= PAGE_SIZE

and the extra note that:

  I only really need it to fail for ALLOC_NO_WATERMARKS, the other
  levels like ALLOC_HIGH and ALLOC_HARDER are not critical.

Which ends up with:

  if the current gfp-context does not allow ALLOC_NO_WATERMARKS
allocations, and alloc_page() fails, so must kmem_cache_alloc(s,) if
kmem_cache_size(s) <= PAGE_SIZE.

(yes this leaves jumbo frames broken)

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2007-08-23 13:00 UTC|newest]

Thread overview: 91+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-20 21:50 [RFC 0/7] Postphone reclaim laundry to write at high water marks Christoph Lameter
2007-08-20 21:50 ` Christoph Lameter
2007-08-20 21:50 ` [RFC 1/7] release_lru_pages(): Generic release of pages to the LRU Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-21 14:52   ` Mel Gorman
2007-08-21 14:52     ` Mel Gorman
2007-08-21 20:51     ` Christoph Lameter
2007-08-21 20:51       ` Christoph Lameter
2007-08-20 21:50 ` [RFC 2/7] Move checks from pageout() to shrink_page_list Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-20 21:50 ` [RFC 3/7] shrink_page_list: Support isolating dirty pages on laundry list Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-21 15:04   ` Mel Gorman
2007-08-21 15:04     ` Mel Gorman
2007-08-21 20:53     ` Christoph Lameter
2007-08-21 20:53       ` Christoph Lameter
2007-08-20 21:50 ` [RFC 4/7] Pass laundry through shrink_inactive_list() and shrink_zone() Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-20 21:50 ` [RFC 5/7] Laundry handling for direct reclaim Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-21 15:06   ` Mel Gorman
2007-08-21 15:06     ` Mel Gorman
2007-08-21 20:55     ` Christoph Lameter
2007-08-21 20:55       ` Christoph Lameter
2007-08-21 15:19   ` Mel Gorman
2007-08-21 15:19     ` Mel Gorman
2007-08-21 21:00     ` Christoph Lameter
2007-08-21 21:00       ` Christoph Lameter
2007-08-20 21:50 ` [RFC 6/7] kswapd: Do laundry after reclaim Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-20 21:50 ` [RFC 7/7] Switch of PF_MEMALLOC during writeout Christoph Lameter
2007-08-20 21:50   ` Christoph Lameter
2007-08-20 23:08   ` Andi Kleen
2007-08-20 23:08     ` Andi Kleen
2007-08-20 23:19     ` Christoph Lameter
2007-08-20 23:19       ` Christoph Lameter
2007-08-21  1:13       ` Andi Kleen
2007-08-21  1:13         ` Andi Kleen
2007-08-21 10:36 ` [RFC 0/7] Postphone reclaim laundry to write at high water marks Peter Zijlstra
2007-08-21 10:36   ` Peter Zijlstra
2007-08-21 20:48   ` Christoph Lameter
2007-08-21 20:48     ` Christoph Lameter
2007-08-21 21:13     ` Peter Zijlstra
2007-08-21 21:13       ` Peter Zijlstra
2007-08-21 21:29       ` Christoph Lameter
2007-08-21 21:29         ` Christoph Lameter
2007-08-21 21:43         ` Rik van Riel
2007-08-21 21:43           ` Rik van Riel
2007-08-21 22:32           ` Christoph Lameter
2007-08-21 22:32             ` Christoph Lameter
2007-08-23 12:05             ` Andrea Arcangeli
2007-08-23 12:05               ` Andrea Arcangeli
2007-08-23 20:23               ` Christoph Lameter
2007-08-23 20:23                 ` Christoph Lameter
2007-08-21 22:09         ` Peter Zijlstra
2007-08-21 22:09           ` Peter Zijlstra
2007-08-21 22:43           ` Christoph Lameter
2007-08-21 22:43             ` Christoph Lameter
2007-08-22  7:02             ` Peter Zijlstra
2007-08-22  7:02               ` Peter Zijlstra
2007-08-22 19:04               ` Christoph Lameter
2007-08-22 19:04                 ` Christoph Lameter
2007-08-22 20:03                 ` Peter Zijlstra
2007-08-22 20:03                   ` Peter Zijlstra
2007-08-22 20:16                   ` Christoph Lameter
2007-08-22 20:16                     ` Christoph Lameter
2007-08-23  7:39                     ` Peter Zijlstra
2007-08-23  7:39                       ` Peter Zijlstra
2007-08-26  4:52                     ` Rik van Riel
2007-08-26  4:52                       ` Rik van Riel
2007-08-23 12:16                   ` Andrea Arcangeli
2007-08-23 12:16                     ` Andrea Arcangeli
2007-08-22  7:45             ` Ingo Molnar
2007-08-22  7:45               ` Ingo Molnar
2007-08-22 19:19               ` Christoph Lameter
2007-08-22 19:19                 ` Christoph Lameter
2007-08-23 12:08           ` Andrea Arcangeli
2007-08-23 12:08             ` Andrea Arcangeli
2007-08-23 12:59             ` Peter Zijlstra [this message]
2007-08-23 12:59               ` Peter Zijlstra
2007-08-21 15:16 ` Rik van Riel
2007-08-21 15:16   ` Rik van Riel
2007-08-21 20:59   ` Christoph Lameter
2007-08-21 20:59     ` Christoph Lameter
2007-08-21 21:14     ` Rik van Riel
2007-08-21 21:14       ` Rik van Riel
2007-08-21 21:30       ` Christoph Lameter
2007-08-21 21:30         ` Christoph Lameter
2007-08-21 15:51 ` Dave McCracken
2007-08-21 15:51   ` Dave McCracken
2007-08-21 21:03   ` 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=1187873988.6114.388.camel@twins \
    --to=peterz@infradead.org \
    --cc=andrea@suse.de \
    --cc=clameter@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.