linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Christoph Lameter <clameter@sgi.com>
Cc: Matt Mackall <mpm@selenic.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Thomas Graf <tgraf@suug.ch>, David Miller <davem@davemloft.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	Daniel Phillips <phillips@google.com>,
	Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH 0/5] make slab gfp fair
Date: Mon, 14 May 2007 22:03:13 +0200	[thread overview]
Message-ID: <1179172994.2942.49.camel@lappy> (raw)
In-Reply-To: <Pine.LNX.4.64.0705141253130.12045@schroedinger.engr.sgi.com>

On Mon, 2007-05-14 at 12:56 -0700, Christoph Lameter wrote:
> On Mon, 14 May 2007, Peter Zijlstra wrote:
> 
> > > You can pull the big switch (only on a SLUB slab I fear) to switch 
> > > off the fast path. Do SetSlabDebug() when allocating a precious 
> > > allocation that should not be gobbled up by lower level processes. 
> > > Then you can do whatever you want in the __slab_alloc debug section and we 
> > > wont care because its not the hot path.
> > 
> > One allocator is all I need; it would just be grand if all could be
> > supported.
> > 
> > So what you suggest is not placing the 'emergency' slab into the regular
> > place so that normal allocations will not be able to find it. Then if an
> > emergency allocation cannot be satified by the regular path, we fall
> > back to the slow path and find the emergency slab.
> 
> Hmmm.. Maybe we could do that.... But what I had in mind was simply to 
> set a page flag (DebugSlab()) if you know in alloc_slab that the slab 
> should be only used for emergency allocation. If DebugSlab is set then the
> fastpath will not be called. You can trap all allocation attempts and 
> insert whatever fancy logic you want in the debug path since its not 
> performance critical.

I might have missed some detail when I looked at SLUB, but I did not see
how setting SlabDebug would trap subsequent allocations to that slab.

> > The thing is; I'm not needing any speed, as long as the machine stay
> > alive I'm good. However others are planing to build a full reserve based
> > allocator to properly fix the places that now use __GFP_NOFAIL and
> > situation such as in add_to_swap().
> 
> Well I have version of SLUB here that allows you do redirect the alloc 
> calls at will. Adds a kmem_cache_ops structure and in the kmem_cache_ops 
> structure you can redirect allocation and freeing of slabs (not objects!) 
> at will. Would that help?

I'm not sure; I need kmalloc as well.

--
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-05-14 20:03 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-14 13:19 Peter Zijlstra
2007-05-14 13:19 ` [PATCH 1/5] mm: page allocation rank Peter Zijlstra
2007-05-14 13:19 ` [PATCH 2/5] mm: slab allocation fairness Peter Zijlstra
2007-05-14 15:51   ` Christoph Lameter
2007-05-14 13:19 ` [PATCH 3/5] mm: slub " Peter Zijlstra
2007-05-14 15:49   ` Christoph Lameter
2007-05-14 16:14     ` Peter Zijlstra
2007-05-14 16:35       ` Christoph Lameter
2007-05-14 13:19 ` [PATCH 4/5] mm: slob " Peter Zijlstra
2007-05-14 13:19 ` [PATCH 5/5] mm: allow mempool to fall back to memalloc reserves Peter Zijlstra
2007-05-14 15:53 ` [PATCH 0/5] make slab gfp fair Christoph Lameter
2007-05-14 16:10   ` Peter Zijlstra
2007-05-14 16:37     ` Christoph Lameter
2007-05-14 16:12   ` Matt Mackall
2007-05-14 16:29     ` Christoph Lameter
2007-05-14 17:40       ` Peter Zijlstra
2007-05-14 17:57         ` Christoph Lameter
2007-05-14 19:28           ` Peter Zijlstra
2007-05-14 19:56             ` Christoph Lameter
2007-05-14 20:03               ` Peter Zijlstra [this message]
2007-05-14 20:06                 ` Christoph Lameter
2007-05-14 20:12                   ` Peter Zijlstra
2007-05-14 20:25                 ` Christoph Lameter
2007-05-15 17:27             ` Peter Zijlstra
2007-05-15 22:02               ` Christoph Lameter
2007-05-16  6:59                 ` Peter Zijlstra
2007-05-16 18:43                   ` Christoph Lameter
2007-05-16 19:25                     ` Peter Zijlstra
2007-05-16 19:53                       ` Christoph Lameter
2007-05-16 20:18                         ` Peter Zijlstra
2007-05-16 20:27                           ` Christoph Lameter
2007-05-16 20:40                             ` Peter Zijlstra
2007-05-16 20:44                               ` Christoph Lameter
2007-05-16 20:54                                 ` Peter Zijlstra
2007-05-16 20:59                                   ` Christoph Lameter
2007-05-16 21:04                                     ` Peter Zijlstra
2007-05-16 21:13                                       ` Christoph Lameter
2007-05-16 21:20                                         ` Peter Zijlstra
2007-05-16 21:42                                           ` Christoph Lameter
2007-05-17  7:28                                             ` Peter Zijlstra
2007-05-17 17:30                                               ` Christoph Lameter
2007-05-17 17:53                                                 ` Peter Zijlstra
2007-05-17 18:01                                                   ` Christoph Lameter
2007-05-14 19:44     ` Andrew Morton
2007-05-14 20:01       ` Matt Mackall
2007-05-14 20:05       ` Peter Zijlstra
2007-05-17  3:02 ` Christoph Lameter
2007-05-17  7:08   ` Peter Zijlstra
2007-05-17 17:29     ` Christoph Lameter
2007-05-17 17:52       ` Peter Zijlstra
2007-05-17 17:59         ` Christoph Lameter
2007-05-17 17:53       ` Matt Mackall
2007-05-17 18:02         ` Christoph Lameter
2007-05-17 19:18           ` Peter Zijlstra
2007-05-17 19:24             ` Christoph Lameter
2007-05-17 21:26               ` Peter Zijlstra
2007-05-17 21:44                 ` Paul Jackson
2007-05-17 22:27                 ` Christoph Lameter
2007-05-18  9:54                   ` Peter Zijlstra
2007-05-18 17:11                     ` Paul Jackson
2007-05-18 17:11                     ` Christoph Lameter
2007-05-20  8:39                       ` Peter Zijlstra
2007-05-21 16:45                         ` Christoph Lameter
2007-05-21 19:33                           ` Peter Zijlstra
2007-05-21 19:43                             ` Christoph Lameter
2007-05-21 20:08                               ` Peter Zijlstra
2007-05-21 20:32                                 ` Christoph Lameter
2007-05-21 20:54                                   ` Peter Zijlstra
2007-05-21 21:04                                     ` 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=1179172994.2942.49.camel@lappy \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=clameter@sgi.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mpm@selenic.com \
    --cc=penberg@cs.helsinki.fi \
    --cc=phillips@google.com \
    --cc=tgraf@suug.ch \
    /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