From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>,
Andrew Morton <akpm@linux-foundation.org>,
Pekka Enberg <penberg@cs.helsinki.fi>,
Nick Piggin <npiggin@suse.de>,
Manfred Spraul <manfred@colorfullife.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH -mm 3/6] slub: introduce __kfree_rcu
Date: Fri, 6 Mar 2009 21:34:44 -0800 [thread overview]
Message-ID: <20090307053444.GB10625@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.DEB.1.10.0903050938300.22053@qirst.com>
On Thu, Mar 05, 2009 at 09:39:03AM -0500, Christoph Lameter wrote:
> On Thu, 5 Mar 2009, Lai Jiangshan wrote:
>
> > The first parameter of __kfree_rcu() is unused in slab,slub,slqb.
> > (I used it before, for CONFIG_SLUB_DEBUG=y ...etc. But I found
> > these debugging code is needless)
> >
> > Object sizes of the memory objects in slob's kmalloc-slab are various.
> > We hardly calculate the start address of the object from the rcu address.
>
> But you can start with the descriptor at the beginning of the page and
> scan until you find the object.
Another approach would be to keep a per-page bitmap of the objects
that are awaiting a grace period.
Not sure whether or not it is worthwhile, but it does reduce the
per-object overhead to two bits (one for the objects awaiting the
current grace period, the other for objects that will await the next
grace period).
Thanx, Paul
next prev parent reply other threads:[~2009-03-07 5:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-03 13:44 Lai Jiangshan
2009-03-04 15:06 ` Christoph Lameter
2009-03-05 1:20 ` Lai Jiangshan
2009-03-05 14:39 ` Christoph Lameter
2009-03-07 5:34 ` Paul E. McKenney [this message]
2009-03-23 7:50 ` Pekka Enberg
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=20090307053444.GB10625@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
--cc=mingo@elte.hu \
--cc=npiggin@suse.de \
--cc=penberg@cs.helsinki.fi \
--cc=peterz@infradead.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