mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, Mel Gorman <mel@csn.ul.ie>,
	Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Subject: Re: [this_cpu_xx V8 03/16] Use this_cpu operations in slub
Date: Sun, 20 Dec 2009 11:11:15 +0200	[thread overview]
Message-ID: <4B2DEA33.7000800@cs.helsinki.fi> (raw)
In-Reply-To: <20091218222649.091070364@quilx.com>

Christoph Lameter wrote:
> Using per cpu allocations removes the needs for the per cpu arrays in the
> kmem_cache struct. These could get quite big if we have to support systems
> with thousands of cpus. The use of this_cpu_xx operations results in:
> 
> 1. The size of kmem_cache for SMP configuration shrinks since we will only
>    need 1 pointer instead of NR_CPUS. The same pointer can be used by all
>    processors. Reduces cache footprint of the allocator.
> 
> 2. We can dynamically size kmem_cache according to the actual nodes in the
>    system meaning less memory overhead for configurations that may potentially
>    support up to 1k NUMA nodes / 4k cpus.
> 
> 3. We can remove the diddle widdle with allocating and releasing of
>    kmem_cache_cpu structures when bringing up and shutting down cpus. The cpu
>    alloc logic will do it all for us. Removes some portions of the cpu hotplug
>    functionality.
> 
> 4. Fastpath performance increases since per cpu pointer lookups and
>    address calculations are avoided.
> 
> V7-V8
> - Convert missed get_cpu_slab() under CONFIG_SLUB_STATS
> 
> Cc: Pekka Enberg <penberg@cs.helsinki.fi>
> Signed-off-by: Christoph Lameter <cl@linux-foundation.org>

Patches 3-6 applied.

  reply	other threads:[~2009-12-20  9:11 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 22:26 [this_cpu_xx V8 00/16] Per cpu atomics in core allocators, cleanup and more this_cpu_ops Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 01/16] this_cpu_ops: page allocator conversion Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 02/16] this_cpu ops: Remove pageset_notifier Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 03/16] Use this_cpu operations in slub Christoph Lameter
2009-12-20  9:11   ` Pekka Enberg [this message]
2009-12-18 22:26 ` [this_cpu_xx V8 04/16] SLUB: Get rid of dynamic DMA kmalloc cache allocation Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 05/16] this_cpu: Remove slub kmem_cache fields Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 06/16] Make slub statistics use this_cpu_inc Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 07/16] Module handling: Use this_cpu_xx to dynamically allocate counters Christoph Lameter
2009-12-21  7:47   ` Tejun Heo
2009-12-21  7:59     ` Tejun Heo
2009-12-21  8:19       ` Tejun Heo
2009-12-21 23:28       ` Rusty Russell
2009-12-22  0:02         ` Tejun Heo
2009-12-22 16:17           ` Christoph Lameter
2009-12-22 15:58       ` Christoph Lameter
2009-12-22 15:57     ` Christoph Lameter
2009-12-23  2:07       ` Tejun Heo
2010-01-04 17:22         ` Christoph Lameter
2010-01-04 17:51           ` Mathieu Desnoyers
2009-12-18 22:26 ` [this_cpu_xx V8 08/16] Remove cpu_local_xx macros Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 09/16] Allow arch to provide inc/dec functionality for each size separately Christoph Lameter
2009-12-21  7:25   ` Tejun Heo
2009-12-22 15:56     ` Christoph Lameter
2009-12-23  2:08       ` Tejun Heo
2009-12-18 22:26 ` [this_cpu_xx V8 10/16] Support generating inc/dec for this_cpu_inc/dec Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 11/16] Generic support for this_cpu_cmpxchg Christoph Lameter
2009-12-19 14:45   ` Mathieu Desnoyers
2009-12-22 15:54     ` Christoph Lameter
2009-12-22 17:24       ` Mathieu Desnoyers
2010-01-04 17:21         ` Christoph Lameter
2010-01-05 22:29           ` Mathieu Desnoyers
2010-01-05 22:35             ` Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 12/16] Add percpu cmpxchg operations Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 13/16] Generic support for this_cpu_xchg Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 14/16] x86 percpu xchg operation Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 15/16] Generic support for this_cpu_add_return() Christoph Lameter
2009-12-18 22:26 ` [this_cpu_xx V8 16/16] x86 support for this_cpu_add_return 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=4B2DEA33.7000800@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=cl@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@polymtl.ca \
    --cc=mel@csn.ul.ie \
    --cc=tj@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

Powered by JetHome