[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090408162651.GA14449@elte.hu>
Date: Wed, 8 Apr 2009 18:26:51 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Christoph Lameter <cl@...ux.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Tejun Heo <tj@...nel.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
linux-kernel@...r.kernel.org, hpa@...or.com,
Paul Mundt <lethal@...ux-sh.org>, rmk@....linux.org.uk,
starvik@...s.com, ralf@...ux-mips.org, davem@...emloft.net,
cooloney@...nel.org, kyle@...artin.ca, matthew@....cx,
grundler@...isc-linux.org, takata@...ux-m32r.org,
benh@...nel.crashing.org, rth@...ddle.net,
ink@...assic.park.msu.ru, heiko.carstens@...ibm.com,
Nick Piggin <npiggin@...e.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the
default percpu allocator
* Christoph Lameter <cl@...ux.com> wrote:
> On Thu, 2 Apr 2009, Ingo Molnar wrote:
>
> > to quote an earlier part of my mail:
> >
> > > > We encourage kfree(NULL) and it triggers commonly in the
> > > > kernel today [on distro kernels we checked it can trigger
> > > > once per syscall!] - so i think we should consider
> > > > free_percpu(NULL) a possibly common pattern too. (even
> > > > though today it's likely _not_ common at all.)
> >
> > I specifically mentioned that it is not at all common now.
>
> What is this? Nonsense day? Consider it a common pattern although
> its likely not common at all? April fools day?
Dude, this is a new facility freshly modernized and freshly made
usable. What did you expect, for a thousand usecases pop up in the
kernel overnight? _None_ of this code is "common" today per se. (the
networking folks are working on making it more and more common
though)
> > But there's no reason why an object shutdown fastpath with an
> > optional percpu buffer (say for debug statistics, not enabled by
> > default) couldnt look like this:
> >
> > percpu_free(NULL);
> >
> > We actually have such patterns of kfree(ptr) use, where the _common_
> > case in a fastpath is kfree(NULL).
>
> Speculation. A shutdown fastpath? The percpu allocation and free
> operations are expensive and deal with teardown and setup of
> virtual mappings. Those paths are *not* optimized for fastpath
> use. kfree is different.
Of course a lot of this is speculation, dynamic percpu so far has
been a rarely used facility compared to kmalloc()/kfree(). If you
dont accept my analogy that's fine - but that is opinion against
opinion - while you state you opinion as truism.
So my point remains: your patch had effects you clearly did not
anticipate, and the cacheline alignment management situation is not
nearly as clear-cut as you imagine it to be.
Unfortunately you failed to answer my detailed mail that made very
specific points though, you only got into generalities and flames
about my summary mail - so it's hard to judge what your opinion
about those specific facts is - you have not stated one.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists