* Pekka Enberg <penberg@xxxxxxxxxxxxxx> wrote:
> Hi Ingo,
>
> On Fri, 2009-02-20 at 10:37 +0100, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> >
> > > Hi all,
> > >
> > > On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> wrote:
> > > >
> > > > @@@ -2723,18 -2689,9 +2727,19 @@@ static void *kmalloc_large_node(size_t
> > > > void *__kmalloc_node(size_t size, gfp_t flags, int node)
> > > > {
> > > > struct kmem_cache *s;
> > > > + void *ret;
> > > >
> > > > - if (unlikely(size > SLUB_MAX_SIZE))
> > > > - return kmalloc_large_node(size, flags, node);
> > > > ++ if (unlikely(size > SLUB_MAX_SIZE)) {
> > > > + if (unlikely(size > PAGE_SIZE)) {
> > >
> > > Except I screwed that up. I meant to delete the last line
> > > above. I will add a patch to the end of linux-next for today.
> >
> > Hm, i'd love to eliminate the conflict, but it would either mean
> > us to pull the slab tree into the tracing tree, or the other way
> > around - and both have quite many items queued up to make this
> > impractical.
>
> Is it a big problem, though? We could do the
> s/PAGE_SIZE/SLUB_MAX_SIZE/g rename as a separate preparational
> patch (without any of the functional changes) and see if Linus
> merges it to mainline...
Linus does not have to merge the changes - it's enough if both
you and me merge it, then there will be no conflicts if the two
trees are combined - Git will sort it all out.
Could you prepare such a patch please, merge it into a separate
(and append-only) branch your tree and then send me a pull
request after a bit of testing so i can merge it into the
tracing tree?
The only constraint is that this commit should never be rebased
after that point - but neither of us will do that.
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
