linux-next: manual merge of the sched tree

linux-next: manual merge of the sched tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the sched tree got a conflict in
include/linux/hardirq.h between commit
17666f02b118099028522dfc3df00a235700e216 ("ftrace: nmi safe code
modification") from the ftrace tree and commit
64db4cfff99c04cd5f550357edcc8780f96b54a2 (""Tree RCU": scalable classic
RCU implementation") from the sched 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 include/linux/hardirq.h
index 89a56d7,9b70b92..0000000
--- a/include/linux/hardirq.h
+++ b/include/linux/hardirq.h
@@@ -162,17 -163,7 +164,19 @@@ extern void irq_enter(void)
   */
  extern void irq_exit(void);
  
 -#define nmi_enter()		do { lockdep_off(); rcu_nmi_enter(); __irq_enter(); } while (0)
 -#define nmi_exit()		do { __irq_exit(); rcu_nmi_exit(); lockdep_on(); } while (0)
 +#define nmi_enter()				\
 +	do {					\
 +		ftrace_nmi_enter();		\
 +		lockdep_off();			\
++		rcu_nmi_enter();		\
 +		__irq_enter();			\
 +	} while (0)
 +#define nmi_exit()				\
 +	do {					\
 +		__irq_exit();			\
++		rcu_nmi_exit();			\
 +		lockdep_on();			\
 +		ftrace_nmi_exit();		\
 +	} while (0)
  
  #endif /* LINUX_HARDIRQ_H */

Re: linux-next: manual merge of the sched tree

[Paul E. McKenney]

On Mon, Dec 22, 2008 at 12:05:43PM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the sched tree got a conflict in
> include/linux/hardirq.h between commit
> 17666f02b118099028522dfc3df00a235700e216 ("ftrace: nmi safe code
> modification") from the ftrace tree and commit
> 64db4cfff99c04cd5f550357edcc8780f96b54a2 (""Tree RCU": scalable classic
> RCU implementation") from the sched tree.
> 
> I fixed it up (see below) and can carry the fix as necessary.

Looks like the right approach to me!

							Thanx, Paul

> -- 
> Cheers,
> Stephen Rothwell                    sfr@canb.auug.org.au
> http://www.canb.auug.org.au/~sfr/
> 
> diff --cc include/linux/hardirq.h
> index 89a56d7,9b70b92..0000000
> --- a/include/linux/hardirq.h
> +++ b/include/linux/hardirq.h
> @@@ -162,17 -163,7 +164,19 @@@ extern void irq_enter(void)
>    */
>   extern void irq_exit(void);
>   
>  -#define nmi_enter()		do { lockdep_off(); rcu_nmi_enter(); __irq_enter(); } while (0)
>  -#define nmi_exit()		do { __irq_exit(); rcu_nmi_exit(); lockdep_on(); } while (0)
>  +#define nmi_enter()				\
>  +	do {					\
>  +		ftrace_nmi_enter();		\
>  +		lockdep_off();			\
> ++		rcu_nmi_enter();		\
>  +		__irq_enter();			\
>  +	} while (0)
>  +#define nmi_exit()				\
>  +	do {					\
>  +		__irq_exit();			\
> ++		rcu_nmi_exit();			\
>  +		lockdep_on();			\
>  +		ftrace_nmi_exit();		\
>  +	} while (0)
>   
>   #endif /* LINUX_HARDIRQ_H */

Re: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>  +#define nmi_enter()				\
>  +	do {					\
>  +		ftrace_nmi_enter();		\
>  +		lockdep_off();			\
> ++		rcu_nmi_enter();		\
>  +		__irq_enter();			\
>  +	} while (0)
>  +#define nmi_exit()				\
>  +	do {					\
>  +		__irq_exit();			\
> ++		rcu_nmi_exit();			\
>  +		lockdep_on();			\
>  +		ftrace_nmi_exit();		\
>  +	} while (0)

yes, that's the same resolution i did for this conflict three days ago in 
tip/master. Thanks,

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 22 Dec 2008 07:35:02 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> >  +#define nmi_enter()				\
> >  +	do {					\
> >  +		ftrace_nmi_enter();		\
> >  +		lockdep_off();			\
> > ++		rcu_nmi_enter();		\
> >  +		__irq_enter();			\
> >  +	} while (0)
> >  +#define nmi_exit()				\
> >  +	do {					\
> >  +		__irq_exit();			\
> > ++		rcu_nmi_exit();			\
> >  +		lockdep_on();			\
> >  +		ftrace_nmi_exit();		\
> >  +	} while (0)
> 
> yes, that's the same resolution i did for this conflict three days ago in 
> tip/master. Thanks,

This conflict is now the sched tree and Linus' tree.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the sched tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the sched tree got a conflict in
kernel/Makefile between commit 65ecc14a30ad21bed9aabdfd6a2ae1a1aaaa6a00
("Remove -mno-spe flags as they dont belong") from Linus' tree and commit
8bb8c4386d08f2cc5d871d22f220d35032213f84 ("sched, ftrace: trace sched.c")
from the sched tree.

I fixed it up (see below) and can carry it for a short while.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

diff --cc kernel/Makefile
index 03a45e7,46e67a3..0000000
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@@ -19,12 -21,7 +19,11 @@@ CFLAGS_REMOVE_mutex-debug.o = -p
  CFLAGS_REMOVE_rtmutex-debug.o = -pg
  CFLAGS_REMOVE_cgroup-debug.o = -pg
  CFLAGS_REMOVE_sched_clock.o = -pg
- CFLAGS_REMOVE_sched.o = -pg
  endif
 +ifdef CONFIG_FUNCTION_RET_TRACER
 +CFLAGS_REMOVE_extable.o = -pg # For __kernel_text_address()
 +CFLAGS_REMOVE_module.o = -pg # For __module_text_address()
 +endif
  
  obj-$(CONFIG_FREEZER) += freezer.o
  obj-$(CONFIG_PROFILING) += profile.o

Re: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the sched tree got a conflict in 
> kernel/Makefile between commit 
> 65ecc14a30ad21bed9aabdfd6a2ae1a1aaaa6a00 ("Remove -mno-spe flags as 
> they dont belong") from Linus' tree and commit 
> 8bb8c4386d08f2cc5d871d22f220d35032213f84 ("sched, ftrace: trace 
> sched.c") from the sched tree.
> 
> I fixed it up (see below) and can carry it for a short while.

i did a similar conflict resolution yesterday. I have pushed out a new 
tip/auto-sched-next branch - you should not see this conflict in the 
future.

Thanks,

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Wed, 19 Nov 2008 09:45:53 +0100 Ingo Molnar <mingo@elte.hu> wrote:
>
> i did a similar conflict resolution yesterday. I have pushed out a new 
> tip/auto-sched-next branch - you should not see this conflict in the 
> future.

Thanks.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sched tree got a conflict in
kernel/sched_fair.c between commit
363ab6f1424cdea63e5d182312d60e19077b892a ("core: use performance variant
for_each_cpu_mask_nr") from the cpus4096 tree and commit
e761b7725234276a802322549cee5255305a0930 ("cpu hotplug, sched: Introduce
cpu_active_map and redo sched domain managment") from the sched tree.

Overlapping addition/modification in wake_idle.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sched tree got a conflict in
include/asm-x86/thread_info.h between commit
64f097331928b01d704047c1dbc738bb6d2a9bf9 ("x86 ptrace: unify
TIF_SINGLESTEP") from the  tree and commit
31656519e132f6612584815f128c83976a9aaaef ("sched, x86: clean up hrtick
implementation") from the sched tree.

The former removes _TIF_SINGLESTEP from _TIF_DO_NOTIFY_MASK, the latter
removes _TIF_HRTICK_RESCHED.  I removed both.  Worth a look when the tree
gets published.

-- 
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: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi all,

On Tue, 22 Jul 2008 11:54:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the sched tree got a conflict in
> include/asm-x86/thread_info.h between commit
> 64f097331928b01d704047c1dbc738bb6d2a9bf9 ("x86 ptrace: unify
> TIF_SINGLESTEP") from the  tree and commit
                        ^^^^
Linus'

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> On Tue, 22 Jul 2008 11:54:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the sched tree got a conflict in
> > include/asm-x86/thread_info.h between commit
> > 64f097331928b01d704047c1dbc738bb6d2a9bf9 ("x86 ptrace: unify
> > TIF_SINGLESTEP") from the  tree and commit
>                         ^^^^
> Linus'

thanks Stephen - i too had a resolution for this, pushed it out into 
auto-sched-next so the linux-next conflict should go away on your next 
iteration.

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Tue, 22 Jul 2008 11:13:26 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> thanks Stephen - i too had a resolution for this, pushed it out into 
> auto-sched-next so the linux-next conflict should go away on your next 
> iteration.

Great, thanks.

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the sched tree got a conflict in 
> kernel/rcupreempt.c between commit 
> 70ff05554f91a1edda1f11684da1dbde09e2feea ("Fix PREEMPT_RCU without 
> HOTPLUG_CPU") from Linus' tree and commit 
> 4446a36ff8c74ac3b32feb009b651048e129c6af ("rcu: add call_rcu_sched()") 
> from the sched tree.
> 
> The former moved rcu_online_cpu() out of the CONFIG_HOTPLUG_CPU ifdef 
> and mode it __cpuinit, while the latter updated it.  I applied the 
> latter updates to the newly positioned function.  This may well not be 
> correct but it does build.  Please check.

yeah, that's how i resolved it too.

	Ingo

Re: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the sched tree got a conflict in 
> include/linux/rculist.h between commit 
> 93921f5c2ce7427cc30341c86882527d1d1d8770 ("Introduce rculist.h") from 
> Linus' tree and commit 82524746c27fa418c250a56dd7606b9d3fc79826 ("rcu: 
> split list.h and move rcu-protected lists into rculist.h") from the 
> sched tree.
> 
> This, of course, was expected and I just took the version in the sched 
> tree and can carry that as a fixup.
> 
> At this point, it would be nice for the places we know that other 
> subsystems need to start using rculist.h to be sent independent 
> patches to do that.  That means creating persusbsystem parts from the 
> latter commit above.  Once they have been integrated, then I can 
> remove several build fix patches that I am carrying in linux-next.  It 
> would have been good if we have done this quite a while ago.

Well, it might have made sense a month or two ago, but now we are a week 
before the merge window so all this does is extra merge complications 
for me and others. So lets wait a week until tip/core/rcu hits upstream 
and then all these complications are resolved in one go, ok?

	Ingo

Re: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Ingo Molnar <mingo@elte.hu> wrote:

> Well, it might have made sense a month or two ago, but now we are a 
> week before the merge window so all this does is extra merge 
> complications for me and others. So lets wait a week until 
> tip/core/rcu hits upstream and then all these complications are 
> resolved in one go, ok?

i.e. next time we see this pattern we should just do the header stub (or 
API stub) immediately, upstream.

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 7 Jul 2008 08:16:34 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> * Ingo Molnar <mingo@elte.hu> wrote:
> 
> i.e. next time we see this pattern we should just do the header stub (or 
> API stub) immediately, upstream.

Correct.  Though we should wait a little to make sure the API is
correct but once it hits -next is probably a good time.

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Mon, 7 Jul 2008 08:16:34 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > * Ingo Molnar <mingo@elte.hu> wrote:
> > 
> > i.e. next time we see this pattern we should just do the header stub 
> > (or API stub) immediately, upstream.
> 
> Correct.  Though we should wait a little to make sure the API is 
> correct but once it hits -next is probably a good time.

i'd wait longer than "it hits -next": to see fallout, to give people 
time to object or to suggest different approaches. (This happened in the 
past, see the tip/sched/new-API-sched_setscheduler API change as an 
example.)

Two weeks after something hits linux-next should be a good rule i guess.

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 7 Jul 2008 08:02:51 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> > At this point, it would be nice for the places we know that other 
> > subsystems need to start using rculist.h to be sent independent 
> > patches to do that.  That means creating persusbsystem parts from the 
> > latter commit above.  Once they have been integrated, then I can 
> > remove several build fix patches that I am carrying in linux-next.  It 
> > would have been good if we have done this quite a while ago.
> 
> Well, it might have made sense a month or two ago, but now we are a week 
> before the merge window so all this does is extra merge complications 
> for me and others. So lets wait a week until tip/core/rcu hits upstream 
> and then all these complications are resolved in one go, ok?

Yeah, that works as well.  I think I just wrote all that to make a point
and see if we can remember to do this sort of thing better and much
earlier next time.

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> index b65871e..7bfdad7 100644
> --- a/arch/x86/mm/kmmio.c
> +++ b/arch/x86/mm/kmmio.c
> @@ -23,6 +23,7 @@
>  #include <linux/errno.h>
>  #include <asm/debugreg.h>
>  #include <linux/mmiotrace.h>
> +#include <linux/rculist.h>

the same commit existed already for about two months:

------------------->
commit 668a6c3654560aef8741642478973e205a4f02bf
Author: Ingo Molnar <mingo@elte.hu>
Date:   Mon May 19 13:35:24 2008 +0200

    - fix mmioftrace + rcu merge interaction
    
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
index b65871e..93d8203 100644
--- a/arch/x86/mm/kmmio.c
+++ b/arch/x86/mm/kmmio.c
@@ -6,6 +6,7 @@
  */
 
 #include <linux/list.h>
+#include <linux/rculist.h>
 #include <linux/spinlock.h>
 #include <linux/hash.h>
 #include <linux/init.h>
<----------------------

so i've merged the tip/tracing/mmiotrace-mergefixups branch into 
tip/tracing/mmiotrace. (after having merged tip/tracing/mmiotrace to 
-rc9 so that rculist.h was present already)

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Mon, 7 Jul 2008 08:10:57 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> 
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> > index b65871e..7bfdad7 100644
> > --- a/arch/x86/mm/kmmio.c
> > +++ b/arch/x86/mm/kmmio.c
> > @@ -23,6 +23,7 @@
> >  #include <linux/errno.h>
> >  #include <asm/debugreg.h>
> >  #include <linux/mmiotrace.h>
> > +#include <linux/rculist.h>
> 
> the same commit existed already for about two months:
> 
> ------------------->
> commit 668a6c3654560aef8741642478973e205a4f02bf
> Author: Ingo Molnar <mingo@elte.hu>
> Date:   Mon May 19 13:35:24 2008 +0200
> 
>     - fix mmioftrace + rcu merge interaction
>     
>     Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> 
> diff --git a/arch/x86/mm/kmmio.c b/arch/x86/mm/kmmio.c
> index b65871e..93d8203 100644
> --- a/arch/x86/mm/kmmio.c
> +++ b/arch/x86/mm/kmmio.c
> @@ -6,6 +6,7 @@
>   */
>  
>  #include <linux/list.h>
> +#include <linux/rculist.h>
>  #include <linux/spinlock.h>
>  #include <linux/hash.h>
>  #include <linux/init.h>
> <----------------------
> 
> so i've merged the tip/tracing/mmiotrace-mergefixups branch into 
> tip/tracing/mmiotrace. (after having merged tip/tracing/mmiotrace to 
> -rc9 so that rculist.h was present already)

Excellent, thanks.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sched tree got a conflict in
kernel/sched.c between commit 040ec23d07f95285e9777a85cda29cb339a3065b
("sched: sched_clock() lockdep fix") from the  tree and commit
76a2a6ee8a0660a29127f05989ac59ae1ce865fa ("sched: sched_clock_cpu() based
cpu_clock()") from the sched tree.

The former updated some code that the latter removed.  I used the version
from the sched tree.

There was also a conflict in kernel/sched_rt.c between commit
363ab6f1424cdea63e5d182312d60e19077b892a ("core: use performance variant
for_each_cpu_mask_nr") from the cpus4096 tree and commit
eff6549b957d15d1ad168d90b8c1eb643b9c163f ("sched: rt: move some code
around") from the sched tree.

Again I took the version from the sched tree except for the
for_each_cpu_mask -> for_each_cpu_mask_nr transformation.

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the sched tree got a conflict in 
> kernel/sched.c between commit 040ec23d07f95285e9777a85cda29cb339a3065b 
> ("sched: sched_clock() lockdep fix") from the tree and commit 
> 76a2a6ee8a0660a29127f05989ac59ae1ce865fa ("sched: sched_clock_cpu() 
> based cpu_clock()") from the sched tree.
> 
> The former updated some code that the latter removed.  I used the 
> version from the sched tree.
> 
> There was also a conflict in kernel/sched_rt.c between commit 
> 363ab6f1424cdea63e5d182312d60e19077b892a ("core: use performance 
> variant for_each_cpu_mask_nr") from the cpus4096 tree and commit 
> eff6549b957d15d1ad168d90b8c1eb643b9c163f ("sched: rt: move some code 
> around") from the sched tree.
> 
> Again I took the version from the sched tree except for the 
> for_each_cpu_mask -> for_each_cpu_mask_nr transformation.

thanks. I did that manual merge a couple of days ago.

You should be able to check whether we both integrated the conflict the 
same way via checking tip/auto-latest, which is the integration of all 
the auto branches that come from -tip.

All the integration branches of -tip are pushed out at once so 
tip/auto-latest always gives a hint about how to integrate two -tip 
derived topic branches, tip/auto-latest always gives an answer. [ which 
might at times be wrong so it never hurts to double check :-) Note: 
auto-latest also includes some non-linux-next topics - but they dont 
affect the scheduler usually. ]

	Ingo

Re: linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi Ingo,

On Tue, 1 Jul 2008 07:54:02 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> You should be able to check whether we both integrated the conflict the 
> same way via checking tip/auto-latest, which is the integration of all 
> the auto branches that come from -tip.
> 
> All the integration branches of -tip are pushed out at once so 
> tip/auto-latest always gives a hint about how to integrate two -tip 
> derived topic branches, tip/auto-latest always gives an answer. [ which 
> might at times be wrong so it never hurts to double check :-) Note: 
> auto-latest also includes some non-linux-next topics - but they dont 
> affect the scheduler usually. ]

Good to know, I will fetch it when necessary to check my work.

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Ingo,
> 
> On Tue, 1 Jul 2008 07:54:02 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > You should be able to check whether we both integrated the conflict the 
> > same way via checking tip/auto-latest, which is the integration of all 
> > the auto branches that come from -tip.
> > 
> > All the integration branches of -tip are pushed out at once so 
> > tip/auto-latest always gives a hint about how to integrate two -tip 
> > derived topic branches, tip/auto-latest always gives an answer. [ which 
> > might at times be wrong so it never hurts to double check :-) Note: 
> > auto-latest also includes some non-linux-next topics - but they dont 
> > affect the scheduler usually. ]
> 
> Good to know, I will fetch it when necessary to check my work.

we could also add tip/auto-next, which would be the integration of 
strictly the topics that go towards linux-next.

You probably dont want to use it for linux-next because it's too large 
hence you'd lose flexibility in shaping the ordering of trees (and lose 
flexibility in excluding broken trees and iterating them out of sync) - 
but it would be useful for the normal case and it might also speed up / 
strengthen your conflict resolution workflow.

	Ingo

linux-next: manual merge of the sched tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the sched tree got a trivial conflict in
kernel/sched_rt.c between commit 363ab6f1424cdea63e5d182312d60e19077b892a
("core: use performance variant for_each_cpu_mask_nr") from the cpus4096
tree and commit eff6549b957d15d1ad168d90b8c1eb643b9c163f ("sched: rt:
move some code around") from the sched tree.

The latter just moved some code that the former modified.  I took the
latter but added the former's modification (for_each_cpu_mask ->
for_each_cpu_mask_nr).

-- 
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: linux-next: manual merge of the sched tree

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next merge of the sched tree got a trivial conflict in 
> kernel/sched_rt.c between commit 
> 363ab6f1424cdea63e5d182312d60e19077b892a ("core: use performance 
> variant for_each_cpu_mask_nr") from the cpus4096 tree and commit 
> eff6549b957d15d1ad168d90b8c1eb643b9c163f ("sched: rt: move some code 
> around") from the sched tree.
> 
> The latter just moved some code that the former modified.  I took the 
> latter but added the former's modification (for_each_cpu_mask -> 
> for_each_cpu_mask_nr).

thanks.

You might want to double-check such resolutions by checking that the end 
result of this file is the same as tip/auto-latest [or tip/master].

Or if it's easier for you we could offer an integration branch of all 
auto-branches in -tip that go towards linux-next. (as we do these same 
tip-internal resolutions ourselves already prior pushing out any of the 
updated -next branches)

	Ingo