Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as thedefault percpu allocator

[Ingo Molnar]

* Christoph Lameter <cl@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/