cpu alloc cleanups and implementation improvement
RFC PATCH 1/1 cpu alloc cleanups and implementation improvement
Hi all,
I've argued with Christoph that his implementation contains gratuitous
obsolescence of perfectly-good APIs; hopefully providing real patches will give us a more useful debate.
It's in easy stages. There are three general cleanup patches, then four
patches to expose the current module percpu allocator as a the general dynamic percpu allocator, then documentation, a new __get_cpu_ptr() primitive and finally a test patch.
I hope this adds some light,
Rusty.
Quoted 3 lines · Rusty Russell
I've argued with Christoph that his implementation contains gratuitous
obsolescence of perfectly-good APIs; hopefully providing real patches will give us a more useful debate.
I would not mind if you would take over from here. It seems that I am into too many things again. Then you can also do the lower casing that I find inconsistent.
Quoted 1 line
I hope this adds some light,
As I pointed out before there are numerous semantic differences that I noted before. For the transition period where the percpu allocator has a fixed area there will be issues with an immediate conversion because the existing allocpercpu allows unbounded allocations and the cpualloc does not.
Hi Christoph,
Quoted 8 lines · On Thu, 20 Nov 2008 10:35:05 -0600 (CST) Christoph Lameter…
Quoted 3 lines · Rusty Russell
I've argued with Christoph that his implementation contains gratuitous
obsolescence of perfectly-good APIs; hopefully providing real patches will give us a more useful debate.I would not mind if you would take over from here.
So, should I remove the cpu_alloc tree from linux-next?
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Quoted 3 lines · Stephen Rothwell
Quoted 1 line
I would not mind if you would take over from here.
So, should I remove the
cpu_alloctree from linux-next?
I think the cpu_alloc branch itself is fine because it only contains the allocator and a single use case. The only point of disagreement at this point is the uppercase / lowercase use. Currently its a separate API (its not replacing allocpercpu) and therefore easy to merge.
The more invasive stuff is stage2 and the following which is not in next yet. The way I envision to go forward is with a gradual transition to the new APIs converting dynamic percpu users to use the new percpu operations and functionality.
The whole thing becomes riskier if we directly replace all allocpercpu users as proposed by Rusty.
Rusty, are you going to take this on?
Quoted 7 lines · On Saturday 22 November 2008 01:19:29 Christoph Lameter wrote:
Quoted 3 lines · Stephen Rothwell
Quoted 1 line
I would not mind if you would take over from here.
So, should I remove the
cpu_alloctree from linux-next?I think the
cpu_allocbranch itself is fine because it only contains the allocator and a single use case.
I think the textual conflicts kill us, but yes, they're orthgonal.
Quoted 4 lines
The more invasive stuff is stage2 and the following which is not in next yet. The way I envision to go forward is with a gradual transition to the new APIs converting dynamic percpu users to use the new percpu operations and functionality.
Yes, and this is the real payoff (though your slub tranformation is pretty sweet too..).
Quoted 4 lines
The whole thing becomes riskier if we directly replace all allocpercpu users as proposed by Rusty.
Rusty, are you going to take this on?
Yes, I think I have to. It's always risky to replace an implementation, but IMHO the current one was always a stopgap.
Sure, the net ones are probably going to have to revert to a boutique old- style percpu allocator until we have growing per-cpu regions. But Dave's already suggested something similar.
Thanks,
Rusty.