Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator

[Christoph Lameter <cl@linux.com>]

On Wed, 8 Apr 2009, Ingo Molnar wrote:

> 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)

?? kfree(NULL) has been allowed for years. None of this is new.

> > 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.


Please look at the kernel source for the use of percpu_free and
percpu_alloc.

> 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.

There was no effect that I did not anticipate. Just imagination on your
part that percpu_free is used like kfree.

Again: The frequent insertion of __read_mostly will
destroy the purpose and function of the read mostly areas!

> 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.

I was pretty clear on those points. Not sure what material question I did
not answer. What you say here fits your posts. Generalizing from kfree to
percpu_free etc...