* linux-next: manual merge of the slab tree with the ftrace tree
@ 2009-01-20 3:57 Stephen Rothwell
2009-01-20 6:01 ` Matt Mackall
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2009-01-20 3:57 UTC (permalink / raw)
To: Pekka Enberg, Christoph Lameter
Cc: linux-next, "Américo Wang", Matt Mackall,
Eduard - Gabriel Munteanu, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin
Hi all,
Today's linux-next merge of the slab tree got a conflict in mm/slob.c
between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
hooks") from the ftrace tree and commit
6e9ed0cc4b963fde66ab47d9fb19147631e44555 ("slob: clean up the code") from
the slab tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc mm/slob.c
index 4d1c0fc,c9cd31d..0000000
--- a/mm/slob.c
+++ b/mm/slob.c
@@@ -475,15 -482,11 +485,15 @@@ void *__kmalloc_node(size_t size, gfp_
if (!m)
return NULL;
*m = size;
- return (void *)m + align;
+ ret = (void *)m + align;
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, size + align, gfp, node);
} else {
- void *ret;
+ unsigned int order = get_order(size);
- ret = slob_new_page(gfp | __GFP_COMP, order, node);
- ret = slob_new_pages(gfp | __GFP_COMP, get_order(size), node);
++ ret = slob_new_pages(gfp | __GFP_COMP, order, node);
if (ret) {
struct page *page;
page = virt_to_page(ret);
@@@ -583,19 -579,10 +593,19 @@@ void *kmem_cache_alloc_node(struct kmem
{
void *b;
- if (c->size < PAGE_SIZE)
+ if (c->size < PAGE_SIZE) {
b = slob_alloc(c->size, flags, c->align, node);
- else
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_CACHE,
+ _RET_IP_, b, c->size,
+ SLOB_UNITS(c->size) * SLOB_UNIT,
+ flags, node);
+ } else {
- b = slob_new_page(flags, get_order(c->size), node);
+ b = slob_new_pages(flags, get_order(c->size), node);
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_CACHE,
+ _RET_IP_, b, c->size,
+ PAGE_SIZE << get_order(c->size),
+ flags, node);
+ }
if (c->ctor)
c->ctor(b);
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-01-20 3:57 Stephen Rothwell
@ 2009-01-20 6:01 ` Matt Mackall
0 siblings, 0 replies; 12+ messages in thread
From: Matt Mackall @ 2009-01-20 6:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Pekka Enberg, Christoph Lameter, linux-next,
"Américo Wang", Eduard - Gabriel Munteanu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
On Tue, 2009-01-20 at 14:57 +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the slab tree got a conflict in mm/slob.c
> between commit 3eae2cb24a96509e0a38cc48dc1538a2826f4e33 ("kmemtrace: SLOB
> hooks") from the ftrace tree and commit
> 6e9ed0cc4b963fde66ab47d9fb19147631e44555 ("slob: clean up the code") from
> the slab tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good, thanks Stephen.
--
http://selenic.com : development and support for Mercurial and Linux
^ permalink raw reply [flat|nested] 12+ messages in thread
* linux-next: manual merge of the slab tree with the ftrace tree
@ 2009-02-20 5:57 Stephen Rothwell
2009-02-20 8:25 ` Pekka Enberg
2009-02-20 8:59 ` Stephen Rothwell
0 siblings, 2 replies; 12+ messages in thread
From: Stephen Rothwell @ 2009-02-20 5:57 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-next, Eduard - Gabriel Munteanu, Pekka Enberg,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
Hi all,
Today's linux-next merge of the slab tree got a conflict in mm/slub.c
between commit 5b882be4e00e53a44f47ad7eb997cac2938848bf ("kmemtrace: SLUB
hooks") from the ftrace tree and commit
8573e12414365585bfd601dc8c093b3efbef8854 ("SLUB: Do not pass 8k objects
through to the page allocator") from the slab tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --cc mm/slub.c
index e6bf32f,23115bd..0000000
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -2689,9 -2661,8 +2693,9 @@@ static struct kmem_cache *get_slab(size
void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
s = get_slab(size, flags);
@@@ -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)) {
+ ret = kmalloc_large_node(size, flags, node);
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, PAGE_SIZE << get_order(size),
+ flags, node);
+
+ return ret;
+ }
s = get_slab(size, flags);
@@@ -3276,9 -3225,8 +3281,9 @@@ static struct notifier_block __cpuinitd
void *__kmalloc_track_caller(size_t size, gfp_t gfpflags, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, gfpflags);
s = get_slab(size, gfpflags);
@@@ -3299,9 -3241,8 +3304,9 @@@ void *__kmalloc_node_track_caller(size_
int node, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, gfpflags, node);
s = get_slab(size, gfpflags);
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 5:57 linux-next: manual merge of the slab tree with the ftrace tree Stephen Rothwell
@ 2009-02-20 8:25 ` Pekka Enberg
2009-02-20 8:59 ` Stephen Rothwell
1 sibling, 0 replies; 12+ messages in thread
From: Pekka Enberg @ 2009-02-20 8:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Christoph Lameter, linux-next, Eduard - Gabriel Munteanu,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
On Fri, 2009-02-20 at 16:57 +1100, Stephen Rothwell wrote:
> Today's linux-next merge of the slab tree got a conflict in mm/slub.c
> between commit 5b882be4e00e53a44f47ad7eb997cac2938848bf ("kmemtrace: SLUB
> hooks") from the ftrace tree and commit
> 8573e12414365585bfd601dc8c093b3efbef8854 ("SLUB: Do not pass 8k objects
> through to the page allocator") from the slab tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Looks good to me! Thanks once again Stephen!
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 5:57 linux-next: manual merge of the slab tree with the ftrace tree Stephen Rothwell
2009-02-20 8:25 ` Pekka Enberg
@ 2009-02-20 8:59 ` Stephen Rothwell
2009-02-20 9:37 ` Ingo Molnar
1 sibling, 1 reply; 12+ messages in thread
From: Stephen Rothwell @ 2009-02-20 8:59 UTC (permalink / raw)
To: Christoph Lameter
Cc: linux-next, Eduard - Gabriel Munteanu, Pekka Enberg,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 708 bytes --]
Hi all,
On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 8:59 ` Stephen Rothwell
@ 2009-02-20 9:37 ` Ingo Molnar
2009-02-20 9:41 ` Pekka Enberg
2009-02-20 22:58 ` Stephen Rothwell
0 siblings, 2 replies; 12+ messages in thread
From: Ingo Molnar @ 2009-02-20 9:37 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Pekka Enberg, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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.
Ingo
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 9:37 ` Ingo Molnar
@ 2009-02-20 9:41 ` Pekka Enberg
2009-02-20 9:53 ` Ingo Molnar
2009-02-20 22:58 ` Stephen Rothwell
1 sibling, 1 reply; 12+ messages in thread
From: Pekka Enberg @ 2009-02-20 9:41 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
Hi Ingo,
On Fri, 2009-02-20 at 10:37 +0100, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> > Hi all,
> >
> > On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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...
Pekka
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 9:41 ` Pekka Enberg
@ 2009-02-20 9:53 ` Ingo Molnar
2009-02-20 11:12 ` Pekka Enberg
0 siblings, 1 reply; 12+ messages in thread
From: Ingo Molnar @ 2009-02-20 9:53 UTC (permalink / raw)
To: Pekka Enberg
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo,
>
> On Fri, 2009-02-20 at 10:37 +0100, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > > Hi all,
> > >
> > > On Fri, 20 Feb 2009 16:57:28 +1100 Stephen Rothwell <sfr@canb.auug.org.au> 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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 9:53 ` Ingo Molnar
@ 2009-02-20 11:12 ` Pekka Enberg
2009-02-20 11:16 ` Ingo Molnar
0 siblings, 1 reply; 12+ messages in thread
From: Pekka Enberg @ 2009-02-20 11:12 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
Hi Ingo,
On Fri, 2009-02-20 at 10:53 +0100, Ingo Molnar wrote:
> > 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?
Aye, aye, cap'n:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-ingo
the commit is here in case someone wants to take a look at it:
http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=fe1200b63d158b28eef6d4de1e5b5f99c681ba2f
Pekka
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 11:12 ` Pekka Enberg
@ 2009-02-20 11:16 ` Ingo Molnar
2009-02-20 23:07 ` Stephen Rothwell
0 siblings, 1 reply; 12+ messages in thread
From: Ingo Molnar @ 2009-02-20 11:16 UTC (permalink / raw)
To: Pekka Enberg
Cc: Stephen Rothwell, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo,
>
> On Fri, 2009-02-20 at 10:53 +0100, Ingo Molnar wrote:
> > > 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?
>
> Aye, aye, cap'n:
>
> git pull git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-ingo
>
> the commit is here in case someone wants to take a look at it:
>
> http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=fe1200b63d158b28eef6d4de1e5b5f99c681ba2f
Pulled into tip:tracing/kmemtrace, thanks Pekka!
Below is the conflict resolution i did. Will push out a new
tip:auto-ftrace-next tree once it got a bit of testing.
Ingo
------------------->
commit 057685cf57066bc8aaed68de1b1970e12f0075d2
Merge: 64b36ca... fe1200b...
Author: Ingo Molnar <mingo@elte.hu>
Date: Fri Feb 20 12:15:30 2009 +0100
Merge branch 'for-ingo' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 into tracing/kmemtrace
Conflicts:
mm/slub.c
diff --cc include/linux/slub_def.h
index 6b657f7,986e09d..9e3a575
--- a/include/linux/slub_def.h
+++ b/include/linux/slub_def.h
@@@ -228,10 -224,8 +241,10 @@@ static __always_inline void *kmalloc_la
static __always_inline void *kmalloc(size_t size, gfp_t flags)
{
+ void *ret;
+
if (__builtin_constant_p(size)) {
- if (size > PAGE_SIZE)
+ if (size > SLUB_MAX_SIZE)
return kmalloc_large(size, flags);
if (!(flags & SLUB_DMA)) {
@@@ -256,26 -244,10 +269,26 @@@
void *__kmalloc_node(size_t size, gfp_t flags, int node);
void *kmem_cache_alloc_node(struct kmem_cache *, gfp_t flags, int node);
+#ifdef CONFIG_KMEMTRACE
+extern void *kmem_cache_alloc_node_notrace(struct kmem_cache *s,
+ gfp_t gfpflags,
+ int node);
+#else
+static __always_inline void *
+kmem_cache_alloc_node_notrace(struct kmem_cache *s,
+ gfp_t gfpflags,
+ int node)
+{
+ return kmem_cache_alloc_node(s, gfpflags, node);
+}
+#endif
+
static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node)
{
+ void *ret;
+
if (__builtin_constant_p(size) &&
- size <= PAGE_SIZE && !(flags & SLUB_DMA)) {
+ size <= SLUB_MAX_SIZE && !(flags & SLUB_DMA)) {
struct kmem_cache *s = kmalloc_slab(size);
if (!s)
diff --cc mm/slub.c
index 3525e7b,5a5e7f5..6de5e07
--- a/mm/slub.c
+++ b/mm/slub.c
@@@ -2688,9 -2657,8 +2688,9 @@@ static struct kmem_cache *get_slab(size
void *__kmalloc(size_t size, gfp_t flags)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, flags);
s = get_slab(size, flags);
@@@ -2722,18 -2685,9 +2722,18 @@@ 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 > PAGE_SIZE)) {
- if (unlikely(size > SLUB_MAX_SIZE))
- return kmalloc_large_node(size, flags, node);
++ if (unlikely(size > SLUB_MAX_SIZE)) {
+ ret = kmalloc_large_node(size, flags, node);
+
+ kmemtrace_mark_alloc_node(KMEMTRACE_TYPE_KMALLOC,
+ _RET_IP_, ret,
+ size, PAGE_SIZE << get_order(size),
+ flags, node);
+
+ return ret;
+ }
s = get_slab(size, flags);
@@@ -3275,9 -3221,8 +3275,9 @@@ static struct notifier_block __cpuinitd
void *__kmalloc_track_caller(size_t size, gfp_t gfpflags, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large(size, gfpflags);
s = get_slab(size, gfpflags);
@@@ -3298,9 -3237,8 +3298,9 @@@ void *__kmalloc_node_track_caller(size_
int node, unsigned long caller)
{
struct kmem_cache *s;
+ void *ret;
- if (unlikely(size > PAGE_SIZE))
+ if (unlikely(size > SLUB_MAX_SIZE))
return kmalloc_large_node(size, gfpflags, node);
s = get_slab(size, gfpflags);
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 9:37 ` Ingo Molnar
2009-02-20 9:41 ` Pekka Enberg
@ 2009-02-20 22:58 ` Stephen Rothwell
1 sibling, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2009-02-20 22:58 UTC (permalink / raw)
To: Ingo Molnar
Cc: Pekka Enberg, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 528 bytes --]
Hi Ingo,
On Fri, 20 Feb 2009 10:37:34 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> 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.
That's OK, I expect to carry several conflict resolutions that only get
fixed during the next merge window.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: linux-next: manual merge of the slab tree with the ftrace tree
2009-02-20 11:16 ` Ingo Molnar
@ 2009-02-20 23:07 ` Stephen Rothwell
0 siblings, 0 replies; 12+ messages in thread
From: Stephen Rothwell @ 2009-02-20 23:07 UTC (permalink / raw)
To: Ingo Molnar
Cc: Pekka Enberg, Christoph Lameter, linux-next,
Eduard - Gabriel Munteanu, Thomas Gleixner, H. Peter Anvin
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]
On Fri, 20 Feb 2009 12:16:51 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> > Aye, aye, cap'n:
> >
> > git pull git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6.git for-ingo
> >
> > the commit is here in case someone wants to take a look at it:
> >
> > http://git.kernel.org/?p=linux/kernel/git/penberg/slab-2.6.git;a=commitdiff;h=fe1200b63d158b28eef6d4de1e5b5f99c681ba2f
>
> Pulled into tip:tracing/kmemtrace, thanks Pekka!
>
> Below is the conflict resolution i did. Will push out a new
> tip:auto-ftrace-next tree once it got a bit of testing.
[I should read more of my mail before replying]
Thanks all - every little bit make my life easier.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2009-02-20 23:07 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-02-20 5:57 linux-next: manual merge of the slab tree with the ftrace tree Stephen Rothwell
2009-02-20 8:25 ` Pekka Enberg
2009-02-20 8:59 ` Stephen Rothwell
2009-02-20 9:37 ` Ingo Molnar
2009-02-20 9:41 ` Pekka Enberg
2009-02-20 9:53 ` Ingo Molnar
2009-02-20 11:12 ` Pekka Enberg
2009-02-20 11:16 ` Ingo Molnar
2009-02-20 23:07 ` Stephen Rothwell
2009-02-20 22:58 ` Stephen Rothwell
-- strict thread matches above, loose matches on Subject: below --
2009-01-20 3:57 Stephen Rothwell
2009-01-20 6:01 ` Matt Mackall
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).