All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Lameter <clameter@engr.sgi.com>
To: Paul Jackson <pj@sgi.com>
Cc: Eric Dumazet <dada1@cosmosbay.com>,
	akpm@osdl.org, linux-kernel@vger.kernel.org,
	nickpiggin@yahoo.com.au, Simon.Derr@bull.net, ak@suse.de
Subject: Re: [PATCH] Cpuset: rcu optimization of page alloc hook
Date: Tue, 13 Dec 2005 13:16:56 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.62.0512131313580.23636@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <20051213130350.464a3054.pj@sgi.com>

On Tue, 13 Dec 2005, Paul Jackson wrote:

> By using a dedicated slab cache, I was able to make an unusual use of
> Hugh Dicken's SLAB_DESTROY_BY_RCU implementation, and access a variable
> inside the cpuset structure safely, even after that cpuset structure
> might have been asynchronously free'd.  What I read from that variable
> might well be garbage, but at least the slab would not have freed that
> page of memory entirely, inside my rcu_read_lock section.

You can accomplish the same thing by using RCU directly without using so 
much storage. (and you said so later ...)

> And when is that memory required?  On many systems, that will have
> cpusets CONFIG_CPUSET enabled, but that are not using cpusets, just
> the kmem_cache_create() will be called to create cpuset_cache, but
> -no- kmem_cache_alloc() calls done.  On those systems using cpusets,
> there might be one 'struct cpuset' allocated per gigabyte of ram, as a
> rough idea.

In this case the slab would allocate one page for the one cpuset. However, 
there are lots of control structures allocated for all nodes that would go
unused. The control structures are allocated when the slab is created.

  reply	other threads:[~2005-12-13 21:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-11 23:31 [PATCH] Cpuset: rcu optimization of page alloc hook Paul Jackson
2005-12-12  3:29 ` Andi Kleen
2005-12-12  6:11   ` Paul Jackson
2005-12-12  6:21     ` Andi Kleen
2005-12-12  6:50       ` Paul Jackson
2005-12-12  8:49 ` Eric Dumazet
2005-12-12  8:54   ` Nick Piggin
2005-12-12  9:06     ` Eric Dumazet
2005-12-12  9:11     ` Andrew Morton
2005-12-12  9:38       ` Nick Piggin
2005-12-12 10:02   ` Paul Jackson
2005-12-12 10:12     ` Andrew Morton
2005-12-13 15:53       ` Paul Jackson
2005-12-13 16:31         ` Eric Dumazet
2005-12-13 17:42           ` Christoph Lameter
2005-12-13 17:56             ` Eric Dumazet
2005-12-13 18:07               ` Christoph Lameter
2005-12-13 21:03               ` Paul Jackson
2005-12-13 21:16                 ` Christoph Lameter [this message]
2005-12-13 21:38                 ` Eric Dumazet
2005-12-13 22:23                   ` Paul Jackson
2005-12-13 22:29                     ` Christoph Lameter
2005-12-14  3:54                     ` Paul Jackson
2005-12-14  4:02                       ` Andi Kleen
2005-12-14  4:06                         ` Paul Jackson
2005-12-14  8:06                     ` Eric Dumazet
2005-12-14  8:40                       ` Paul Jackson
2005-12-13 20:08           ` Paul Jackson
2005-12-13 20:29             ` Eric Dumazet
2005-12-13 22:35               ` Paul Jackson
2005-12-13 21:44           ` Paul Jackson
2005-12-13 17:37         ` 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=Pine.LNX.4.62.0512131313580.23636@schroedinger.engr.sgi.com \
    --to=clameter@engr.sgi.com \
    --cc=Simon.Derr@bull.net \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=dada1@cosmosbay.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pj@sgi.com \
    /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.