All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Mel Gorman <mgorman@suse.de>, Pekka Enberg <penberg@kernel.org>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT
Date: Wed, 20 Jul 2011 16:08:13 +0200	[thread overview]
Message-ID: <1311170893.2338.29.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> (raw)
In-Reply-To: <alpine.DEB.2.00.1107200854390.32737@router.home>

Le mercredi 20 juillet 2011 à 08:56 -0500, Christoph Lameter a écrit :
> On Wed, 20 Jul 2011, Mel Gorman wrote:
> 
> > > The changelog isn't that convincing, really. This is
> > > kmem_cache_create() so I'm surprised we'd ever get NULL here in
> > > practice. Does this fix some problem you're seeing? If this is
> > > really an issue, I'd blame the page allocator as GFP_KERNEL should
> > > just work.
> > >
> >
> > Besides, is allocating from cache_cache really a
> > PAGE_ALLOC_COSTLY_ORDER allocation? On my laptop at least, it's an
> > order-2 allocation which is supporting up to 512 CPUs and 512 nodes.
> 
> Slab's kmem_cache is configured with an array of NR_CPUS which is the
> maximum nr of cpus supported. Some distros support 4096 cpus in order to
> accomodate SGI machines. That array then will have the size of 4096 * 8 =
> 32k

We currently support a dynamic schem for the possible nodes :

cache_cache.buffer_size = offsetof(struct kmem_cache, nodelists) + 
	nr_node_ids * sizeof(struct kmem_list3 *);

We could have a similar trick to make the real size both depends on
nr_node_ids and nr_cpu_ids.

(struct kmem_cache)->array would become a pointer.




WARNING: multiple messages have this Message-ID (diff)
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Christoph Lameter <cl@linux.com>
Cc: Mel Gorman <mgorman@suse.de>, Pekka Enberg <penberg@kernel.org>,
	Konstantin Khlebnikov <khlebnikov@openvz.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Matt Mackall <mpm@selenic.com>
Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT
Date: Wed, 20 Jul 2011 16:08:13 +0200	[thread overview]
Message-ID: <1311170893.2338.29.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> (raw)
In-Reply-To: <alpine.DEB.2.00.1107200854390.32737@router.home>

Le mercredi 20 juillet 2011 A  08:56 -0500, Christoph Lameter a A(C)crit :
> On Wed, 20 Jul 2011, Mel Gorman wrote:
> 
> > > The changelog isn't that convincing, really. This is
> > > kmem_cache_create() so I'm surprised we'd ever get NULL here in
> > > practice. Does this fix some problem you're seeing? If this is
> > > really an issue, I'd blame the page allocator as GFP_KERNEL should
> > > just work.
> > >
> >
> > Besides, is allocating from cache_cache really a
> > PAGE_ALLOC_COSTLY_ORDER allocation? On my laptop at least, it's an
> > order-2 allocation which is supporting up to 512 CPUs and 512 nodes.
> 
> Slab's kmem_cache is configured with an array of NR_CPUS which is the
> maximum nr of cpus supported. Some distros support 4096 cpus in order to
> accomodate SGI machines. That array then will have the size of 4096 * 8 =
> 32k

We currently support a dynamic schem for the possible nodes :

cache_cache.buffer_size = offsetof(struct kmem_cache, nodelists) + 
	nr_node_ids * sizeof(struct kmem_list3 *);

We could have a similar trick to make the real size both depends on
nr_node_ids and nr_cpu_ids.

(struct kmem_cache)->array would become a pointer.



--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2011-07-20 14:08 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-20 12:16 [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT Konstantin Khlebnikov
2011-07-20 12:16 ` Konstantin Khlebnikov
2011-07-20 13:14 ` Pekka Enberg
2011-07-20 13:14   ` Pekka Enberg
2011-07-20 13:28   ` Konstantin Khlebnikov
2011-07-20 13:28     ` Konstantin Khlebnikov
2011-07-20 13:42     ` Pekka Enberg
2011-07-20 13:42       ` Pekka Enberg
2011-07-20 13:50       ` Konstantin Khlebnikov
2011-07-20 13:50         ` Konstantin Khlebnikov
2011-07-20 13:53         ` Pekka Enberg
2011-07-20 13:53           ` Pekka Enberg
2011-07-20 15:36           ` Christoph Lameter
2011-07-20 15:36             ` Christoph Lameter
2011-07-20 13:59         ` Konstantin Khlebnikov
2011-07-20 13:59           ` Konstantin Khlebnikov
2011-07-20 13:54       ` Christoph Lameter
2011-07-20 13:54         ` Christoph Lameter
2011-07-20 14:20         ` Mel Gorman
2011-07-20 14:20           ` Mel Gorman
2011-07-20 14:32           ` Konstantin Khlebnikov
2011-07-20 14:32             ` Konstantin Khlebnikov
2011-07-20 14:40             ` Eric Dumazet
2011-07-20 14:40               ` Eric Dumazet
2011-07-20 14:47               ` Konstantin Khlebnikov
2011-07-20 14:47                 ` Konstantin Khlebnikov
2011-07-20 13:43   ` Mel Gorman
2011-07-20 13:43     ` Mel Gorman
2011-07-20 13:56     ` Christoph Lameter
2011-07-20 13:56       ` Christoph Lameter
2011-07-20 14:08       ` Eric Dumazet [this message]
2011-07-20 14:08         ` Eric Dumazet
2011-07-20 14:52         ` Christoph Lameter
2011-07-20 14:52           ` Christoph Lameter
2011-07-20 15:09           ` Eric Dumazet
2011-07-20 15:09             ` Eric Dumazet
2011-07-20 15:34             ` Christoph Lameter
2011-07-20 15:34               ` Christoph Lameter
2011-07-20 15:56               ` Eric Dumazet
2011-07-20 15:56                 ` Eric Dumazet
2011-07-20 16:17                 ` Christoph Lameter
2011-07-20 16:17                   ` Christoph Lameter
2011-07-20 16:31                   ` Eric Dumazet
2011-07-20 16:31                     ` Eric Dumazet
2011-07-20 17:04                     ` Eric Dumazet
2011-07-20 17:04                       ` Eric Dumazet
2011-07-20 17:13                       ` Christoph Lameter
2011-07-20 17:13                         ` Christoph Lameter
2011-07-20 17:28                         ` Pekka Enberg
2011-07-20 17:28                           ` Pekka Enberg
2011-07-20 17:37                           ` Christoph Lameter
2011-07-20 17:37                             ` Christoph Lameter
2011-07-20 17:41                             ` Pekka Enberg
2011-07-20 17:41                               ` Pekka Enberg
2011-07-20 18:07                               ` Matt Mackall
2011-07-20 18:07                                 ` Matt Mackall
2011-07-21  7:18                                 ` Konstantin Khlebnikov
2011-07-21  7:18                                   ` Konstantin Khlebnikov
2011-07-20 19:09                               ` Mel Gorman
2011-07-20 19:09                                 ` Mel Gorman
2011-07-31 11:41             ` Konstantin Khlebnikov
2011-07-31 11:41               ` Konstantin Khlebnikov
2011-07-31 11:44               ` Pekka Enberg
2011-07-31 11:44                 ` Pekka Enberg
2011-07-21  8:43           ` Eric Dumazet
2011-07-21  8:43             ` Eric Dumazet
2011-07-21 15:27             ` 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=1311170893.2338.29.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC \
    --to=eric.dumazet@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=khlebnikov@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@suse.de \
    --cc=mpm@selenic.com \
    --cc=penberg@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 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.