Messages in this thread | | | Date | Mon, 13 Apr 2009 14:18:08 -0400 (EDT) | From | Christoph Lameter <> | Subject | Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator |
| |
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...
| |