[PATCH RFC] cpu alloc cleanups and implementation improvement

[PATCH RFC] cpu alloc cleanups and implementation improvement

[Rusty Russell]

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.

Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

[Christoph Lameter]

On Mon, 17 Nov 2008, Rusty Russell wrote:

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

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

Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 579 bytes --]

Hi Christoph,

On Thu, 20 Nov 2008 10:35:05 -0600 (CST) Christoph Lameter <cl@linux-foundation.org> wrote:
>
> On Mon, 17 Nov 2008, Rusty Russell wrote:
> 
> >   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?
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

[Christoph Lameter]

On Fri, 21 Nov 2008, Stephen Rothwell wrote:

> > I would not mind if you would take over from here.
>
> So, should I remove the cpu_alloc tree 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?

Re: [PATCH RFC] cpu alloc cleanups and implementation improvement

[Rusty Russell]

On Saturday 22 November 2008 01:19:29 Christoph Lameter wrote:
> On Fri, 21 Nov 2008, Stephen Rothwell wrote:
> > > I would not mind if you would take over from here.
> >
> > So, should I remove the cpu_alloc tree from linux-next?
>
> I think the cpu_alloc branch 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.

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

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