From: Rusty Russell <rusty@rustcorp.com.au>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC] cpu alloc cleanups and implementation improvement
Date: Sat, 22 Nov 2008 15:11:38 +1030 [thread overview]
Message-ID: <200811221511.39434.rusty@rustcorp.com.au> (raw)
In-Reply-To: <Pine.LNX.4.64.0811210842580.24965@quilx.com>
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.
prev parent reply other threads:[~2008-11-23 9:33 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-17 13:23 [PATCH RFC] cpu alloc cleanups and implementation improvement Rusty Russell
2008-11-20 16:35 ` Christoph Lameter
2008-11-21 5:31 ` Stephen Rothwell
2008-11-21 14:49 ` Christoph Lameter
2008-11-22 4:41 ` Rusty Russell [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811221511.39434.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.