linux-next: manual merge of the workqueues tree with the tip tree

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the workqueues tree got a conflict in:

  kernel/workqueue.c

between commit:

  5a6446626d7e ("workqueue: Convert for_each_wq to use built-in list check")

from the tip tree and commit:

  49e9d1a9faf2 ("workqueue: Add RCU annotation for pwq list walk")

from the workqueues tree.

I fixed it up (I just used the former as it is a superset of the latter)
and can carry the fix as necessary. This is now fixed as far as linux-next
is concerned, but any non trivial conflicts should be mentioned to your
upstream maintainer when your tree is submitted for merging.  You may
also want to consider cooperating with the maintainer of the conflicting
tree to minimise any particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Sebastian Andrzej Siewior]

On 2019-11-18 15:08:58 [+1100], Stephen Rothwell wrote:
> Hi all,
Hi,

> Today's linux-next merge of the workqueues tree got a conflict in:
> 
>   kernel/workqueue.c
> 
> between commit:
> 
>   5a6446626d7e ("workqueue: Convert for_each_wq to use built-in list check")
> 
> from the tip tree and commit:
> 
>   49e9d1a9faf2 ("workqueue: Add RCU annotation for pwq list walk")
> 
> from the workqueues tree.

urgh. So the RCU warning is introduced in commit
   28875945ba98d ("rcu: Add support for consolidated-RCU reader checking")

which was merged in v5.4-rc1. I enabled it around -rc7 and saw a few
warnings including in the workqueue code. I asked about this and posted
later a patch which was applied by Tejun. Now I see that the tip tree
has a patch for this warning…
I would vote for the patch in -tip since it also removes the
assert_rcu_or_wq_mutex() macro.
It would be nice if this could be part of v5.4 since once the RCU
warning is enabled it will yell.

Sebastian

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Ingo Molnar]

* Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:

> On 2019-11-18 15:08:58 [+1100], Stephen Rothwell wrote:
> > Hi all,
> Hi,
> 
> > Today's linux-next merge of the workqueues tree got a conflict in:
> > 
> >   kernel/workqueue.c
> > 
> > between commit:
> > 
> >   5a6446626d7e ("workqueue: Convert for_each_wq to use built-in list check")
> > 
> > from the tip tree and commit:
> > 
> >   49e9d1a9faf2 ("workqueue: Add RCU annotation for pwq list walk")
> > 
> > from the workqueues tree.
> 
> urgh. So the RCU warning is introduced in commit
>    28875945ba98d ("rcu: Add support for consolidated-RCU reader checking")
> 
> which was merged in v5.4-rc1. I enabled it around -rc7 and saw a few
> warnings including in the workqueue code. I asked about this and posted
> later a patch which was applied by Tejun. Now I see that the tip tree
> has a patch for this warning…
> I would vote for the patch in -tip since it also removes the
> assert_rcu_or_wq_mutex() macro.
> It would be nice if this could be part of v5.4 since once the RCU
> warning is enabled it will yell.

So 5a6446626d7e is currently queued up for v5.5 as part of the RCU tree. 

I can cherry pick 5a6446626d7e into tip:core/urgent if Paul and Tejun 
agree.

Thanks,

	Ingo

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Paul E. McKenney]

On Mon, Nov 18, 2019 at 01:50:46PM +0100, Ingo Molnar wrote:
> 
> * Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> 
> > On 2019-11-18 15:08:58 [+1100], Stephen Rothwell wrote:
> > > Hi all,
> > Hi,
> > 
> > > Today's linux-next merge of the workqueues tree got a conflict in:
> > > 
> > >   kernel/workqueue.c
> > > 
> > > between commit:
> > > 
> > >   5a6446626d7e ("workqueue: Convert for_each_wq to use built-in list check")
> > > 
> > > from the tip tree and commit:
> > > 
> > >   49e9d1a9faf2 ("workqueue: Add RCU annotation for pwq list walk")
> > > 
> > > from the workqueues tree.
> > 
> > urgh. So the RCU warning is introduced in commit
> >    28875945ba98d ("rcu: Add support for consolidated-RCU reader checking")
> > 
> > which was merged in v5.4-rc1. I enabled it around -rc7 and saw a few
> > warnings including in the workqueue code. I asked about this and posted
> > later a patch which was applied by Tejun. Now I see that the tip tree
> > has a patch for this warning…
> > I would vote for the patch in -tip since it also removes the
> > assert_rcu_or_wq_mutex() macro.
> > It would be nice if this could be part of v5.4 since once the RCU
> > warning is enabled it will yell.
> 
> So 5a6446626d7e is currently queued up for v5.5 as part of the RCU tree. 
> 
> I can cherry pick 5a6446626d7e into tip:core/urgent if Paul and Tejun 
> agree.

No objections here.

							Thanx, Paul

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Tejun Heo]

On Mon, Nov 18, 2019 at 01:50:46PM +0100, Ingo Molnar wrote:
> So 5a6446626d7e is currently queued up for v5.5 as part of the RCU tree. 
> 
> I can cherry pick 5a6446626d7e into tip:core/urgent if Paul and Tejun 
> agree.

Yeah, please go ahead.

Thanks.

-- 
tejun

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

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

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
arch/x86/include/asm/percpu.h between commit cebef5beed3d ("x86: Fix and
improve percpu_cmpxchg{8,16}b_double()") from the tip tree and commit
933393f58fef ("percpu: Remove irqsafe_cpu_xxx variants") from the
workqueues tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc arch/x86/include/asm/percpu.h
index 529bf07e,562ccb5..0000000
--- a/arch/x86/include/asm/percpu.h
+++ b/arch/x86/include/asm/percpu.h
@@@ -462,9 -446,8 +443,8 @@@ do {									
  	__ret;								\
  })
  
 -#define __this_cpu_cmpxchg_double_4(pcp1, pcp2, o1, o2, n1, n2)		percpu_cmpxchg8b_double(pcp1, o1, o2, n1, n2)
 -#define this_cpu_cmpxchg_double_4(pcp1, pcp2, o1, o2, n1, n2)		percpu_cmpxchg8b_double(pcp1, o1, o2, n1, n2)
 +#define __this_cpu_cmpxchg_double_4	percpu_cmpxchg8b_double
 +#define this_cpu_cmpxchg_double_4	percpu_cmpxchg8b_double
- #define irqsafe_cpu_cmpxchg_double_4	percpu_cmpxchg8b_double
  #endif /* CONFIG_X86_CMPXCHG64 */
  
  /*
@@@ -519,9 -503,8 +492,8 @@@
  	__ret;								\
  })
  
 -#define __this_cpu_cmpxchg_double_8(pcp1, pcp2, o1, o2, n1, n2)		percpu_cmpxchg16b_double(pcp1, o1, o2, n1, n2)
 -#define this_cpu_cmpxchg_double_8(pcp1, pcp2, o1, o2, n1, n2)		percpu_cmpxchg16b_double(pcp1, o1, o2, n1, n2)
 +#define __this_cpu_cmpxchg_double_8	percpu_cmpxchg16b_double
 +#define this_cpu_cmpxchg_double_8	percpu_cmpxchg16b_double
- #define irqsafe_cpu_cmpxchg_double_8	percpu_cmpxchg16b_double
  
  #endif
  

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

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

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

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
drivers/rtc/rtc-dev.c between commit
042620a018afcfba1d678062b62e463b9e43a68d ("RTC: Remove UIE emulation")
from the  tree and commit 9db8995be5e1869b5effa117909bc285e06fc09b ("rtc:
don't use flush_scheduled_work()") from the workqueues tree.

The former removes the code that the latter modifies, so I used the
former.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

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

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit
a25909a4d4a29e272f953e12595bf2f04a292dbd ("lockdep: Add an
in_workqueue_context() lockdep-based test function") from the tip tree
and commit 098849516dd522a343e659740c8f1394a5b7fa69 ("workqueue: explain
for_each_*cwq_cpu() iterators") from the workqueues tree (alogn with a
few others that were previously reported).

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/workqueue.c
index 59fef15,e2eb351..0000000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -68,21 -237,68 +237,83 @@@ struct workqueue_struct 
  #endif
  };
  
 +#ifdef CONFIG_LOCKDEP
 +/**
 + * in_workqueue_context() - in context of specified workqueue?
 + * @wq: the workqueue of interest
 + *
 + * Checks lockdep state to see if the current task is executing from
 + * within a workqueue item.  This function exists only if lockdep is
 + * enabled.
 + */
 +int in_workqueue_context(struct workqueue_struct *wq)
 +{
 +	return lock_is_held(&wq->lockdep_map);
 +}
 +#endif
 +
+ struct workqueue_struct *system_wq __read_mostly;
+ struct workqueue_struct *system_long_wq __read_mostly;
+ struct workqueue_struct *system_nrt_wq __read_mostly;
+ struct workqueue_struct *system_unbound_wq __read_mostly;
+ EXPORT_SYMBOL_GPL(system_wq);
+ EXPORT_SYMBOL_GPL(system_long_wq);
+ EXPORT_SYMBOL_GPL(system_nrt_wq);
+ EXPORT_SYMBOL_GPL(system_unbound_wq);
+ 
+ #define for_each_busy_worker(worker, i, pos, gcwq)			\
+ 	for (i = 0; i < BUSY_WORKER_HASH_SIZE; i++)			\
+ 		hlist_for_each_entry(worker, pos, &gcwq->busy_hash[i], hentry)
+ 
+ static inline int __next_gcwq_cpu(int cpu, const struct cpumask *mask,
+ 				  unsigned int sw)
+ {
+ 	if (cpu < nr_cpu_ids) {
+ 		if (sw & 1) {
+ 			cpu = cpumask_next(cpu, mask);
+ 			if (cpu < nr_cpu_ids)
+ 				return cpu;
+ 		}
+ 		if (sw & 2)
+ 			return WORK_CPU_UNBOUND;
+ 	}
+ 	return WORK_CPU_NONE;
+ }
+ 
+ static inline int __next_wq_cpu(int cpu, const struct cpumask *mask,
+ 				struct workqueue_struct *wq)
+ {
+ 	return __next_gcwq_cpu(cpu, mask, !(wq->flags & WQ_UNBOUND) ? 1 : 2);
+ }
+ 
+ /*
+  * CPU iterators
+  *
+  * An extra gcwq is defined for an invalid cpu number
+  * (WORK_CPU_UNBOUND) to host workqueues which are not bound to any
+  * specific CPU.  The following iterators are similar to
+  * for_each_*_cpu() iterators but also considers the unbound gcwq.
+  *
+  * for_each_gcwq_cpu()		: possible CPUs + WORK_CPU_UNBOUND
+  * for_each_online_gcwq_cpu()	: online CPUs + WORK_CPU_UNBOUND
+  * for_each_cwq_cpu()		: possible CPUs for bound workqueues,
+  *				  WORK_CPU_UNBOUND for unbound workqueues
+  */
+ #define for_each_gcwq_cpu(cpu)						\
+ 	for ((cpu) = __next_gcwq_cpu(-1, cpu_possible_mask, 3);		\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_gcwq_cpu((cpu), cpu_possible_mask, 3))
+ 
+ #define for_each_online_gcwq_cpu(cpu)					\
+ 	for ((cpu) = __next_gcwq_cpu(-1, cpu_online_mask, 3);		\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_gcwq_cpu((cpu), cpu_online_mask, 3))
+ 
+ #define for_each_cwq_cpu(cpu, wq)					\
+ 	for ((cpu) = __next_wq_cpu(-1, cpu_possible_mask, (wq));	\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_wq_cpu((cpu), cpu_possible_mask, (wq)))
+ 
  #ifdef CONFIG_DEBUG_OBJECTS_WORK
  
  static struct debug_obj_descr work_debug_descr;

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/trace/Kconfig between commit
039ca4e74a1cf60bd7487324a564ecf5c981f254 ("tracing: Remove kmemtrace
ftrace plugin") from the tip tree and commit
64166699752006f1a23a9cf7c96ae36654ccfc2c ("workqueue: temporarily remove
workqueue tracing") from the workqueues tree.

Juts context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/trace/Kconfig
index f669092,a0d95c1f..0000000
--- a/kernel/trace/Kconfig
+++ b/kernel/trace/Kconfig
@@@ -354,17 -371,26 +354,6 @@@ config STACK_TRACE
  
  	  Say N if unsure.
  
- config WORKQUEUE_TRACER
- 	bool "Trace workqueues"
- 	select GENERIC_TRACER
- 	help
- 	  The workqueue tracer provides some statistical information
-           about each cpu workqueue thread such as the number of the
-           works inserted and executed since their creation. It can help
-           to evaluate the amount of work each of them has to perform.
-           For example it can help a developer to decide whether he should
-           choose a per-cpu workqueue instead of a singlethreaded one.
- 
 -config KMEMTRACE
 -	bool "Trace SLAB allocations"
 -	select GENERIC_TRACER
 -	help
 -	  kmemtrace provides tracing for slab allocator functions, such as
 -	  kmalloc, kfree, kmem_cache_alloc, kmem_cache_free, etc. Collected
 -	  data is then fed to the userspace application in order to analyse
 -	  allocation hotspots, internal fragmentation and so on, making it
 -	  possible to see how well an allocator performs, as well as debug
 -	  and profile kernel code.
 -
 -	  This requires an userspace application to use. See
 -	  Documentation/trace/kmemtrace.txt for more information.
 -
 -	  Saying Y will make the kernel somewhat larger and slower. However,
 -	  if you disable kmemtrace at run-time or boot-time, the performance
 -	  impact is minimal (depending on the arch the kernel is built for).
 -
 -	  If unsure, say N.
 -
  config BLK_DEV_IO_TRACE
  	bool "Support for tracing block IO actions"
  	depends on SYSFS

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/workqueue.c between commit
a25909a4d4a29e272f953e12595bf2f04a292dbd ("lockdep: Add an
in_workqueue_context() lockdep-based test function") from the tip tree
and several commits from the workqueues tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/workqueue.c
index 59fef15,aca9472..0000000
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@@ -68,21 -216,55 +216,70 @@@ struct workqueue_struct 
  #endif
  };
  
+ struct workqueue_struct *system_wq __read_mostly;
+ struct workqueue_struct *system_long_wq __read_mostly;
+ struct workqueue_struct *system_nrt_wq __read_mostly;
+ struct workqueue_struct *system_unbound_wq __read_mostly;
+ EXPORT_SYMBOL_GPL(system_wq);
+ EXPORT_SYMBOL_GPL(system_long_wq);
+ EXPORT_SYMBOL_GPL(system_nrt_wq);
+ EXPORT_SYMBOL_GPL(system_unbound_wq);
+ 
+ #define for_each_busy_worker(worker, i, pos, gcwq)			\
+ 	for (i = 0; i < BUSY_WORKER_HASH_SIZE; i++)			\
+ 		hlist_for_each_entry(worker, pos, &gcwq->busy_hash[i], hentry)
+ 
+ static inline int __next_gcwq_cpu(int cpu, const struct cpumask *mask,
+ 				  unsigned int sw)
+ {
+ 	if (cpu < nr_cpu_ids) {
+ 		if (sw & 1) {
+ 			cpu = cpumask_next(cpu, mask);
+ 			if (cpu < nr_cpu_ids)
+ 				return cpu;
+ 		}
+ 		if (sw & 2)
+ 			return WORK_CPU_UNBOUND;
+ 	}
+ 	return WORK_CPU_NONE;
+ }
+ 
+ static inline int __next_wq_cpu(int cpu, const struct cpumask *mask,
+ 				struct workqueue_struct *wq)
+ {
+ 	return __next_gcwq_cpu(cpu, mask, !(wq->flags & WQ_UNBOUND) ? 1 : 2);
+ }
+ 
+ #define for_each_gcwq_cpu(cpu)						\
+ 	for ((cpu) = __next_gcwq_cpu(-1, cpu_possible_mask, 3);		\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_gcwq_cpu((cpu), cpu_possible_mask, 3))
+ 
+ #define for_each_online_gcwq_cpu(cpu)					\
+ 	for ((cpu) = __next_gcwq_cpu(-1, cpu_online_mask, 3);		\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_gcwq_cpu((cpu), cpu_online_mask, 3))
+ 
+ #define for_each_cwq_cpu(cpu, wq)					\
+ 	for ((cpu) = __next_wq_cpu(-1, cpu_possible_mask, (wq));	\
+ 	     (cpu) < WORK_CPU_NONE;					\
+ 	     (cpu) = __next_wq_cpu((cpu), cpu_possible_mask, (wq)))
+ 
 +#ifdef CONFIG_LOCKDEP
 +/**
 + * in_workqueue_context() - in context of specified workqueue?
 + * @wq: the workqueue of interest
 + *
 + * Checks lockdep state to see if the current task is executing from
 + * within a workqueue item.  This function exists only if lockdep is
 + * enabled.
 + */
 +int in_workqueue_context(struct workqueue_struct *wq)
 +{
 +	return lock_is_held(&wq->lockdep_map);
 +}
 +#endif
 +
  #ifdef CONFIG_DEBUG_OBJECTS_WORK
  
  static struct debug_obj_descr work_debug_descr;

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
include/linux/workqueue.h between commit
a25909a4d4a29e272f953e12595bf2f04a292dbd ("lockdep: Add an
in_workqueue_context() lockdep-based test function") from the tip tree
and commit a0a1a5fd4fb15ec61117c759fe9f5c16c53d9e9c ("workqueue:
reimplement workqueue freeze using max_active") from the workqueues tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/workqueue.h
index d0f7c81,d74a529..0000000
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@@ -298,7 -394,10 +394,14 @@@ static inline long work_on_cpu(unsigne
  long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg);
  #endif /* CONFIG_SMP */
  
 +#ifdef CONFIG_LOCKDEP
 +int in_workqueue_context(struct workqueue_struct *wq);
 +#endif
++
+ #ifdef CONFIG_FREEZER
+ extern void freeze_workqueues_begin(void);
+ extern bool freeze_workqueues_busy(void);
+ extern void thaw_workqueues(void);
+ #endif /* CONFIG_FREEZER */
+ 
  #endif

linux-next: manual merge of the workqueues tree with the tip tree

[Stephen Rothwell]

Hi Tejun,

Today's linux-next merge of the workqueues tree got a conflict in
kernel/sched.c between commit eae0c9dfb534cb3449888b9601228efa6480fdb5
("sched: Fix and clean up rate-limit newidle code") from the tip tree and
commit 710c15b748f5ce9c573cc047f419cf007a677a9a ("sched: refactor
try_to_wake_up() and implement try_to_wake_up_local()") from the
workqueues tree.

I did the following fixup which should be checked ... I can carry this
fix (if it is suitable).

However, I have gone back to a previous version of the workqueues tree
for another issue (build problem for an interaction with the sound tree),
so this is not in linux-next today.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc kernel/sched.c
index 686be36,e488e07..0000000
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@@ -2323,7 -2336,58 +2335,69 @@@ void task_oncpu_function_call(struct ta
  	preempt_enable();
  }
  
- /***
+ static inline void ttwu_activate(struct task_struct *p, struct rq *rq,
+ 				 bool is_sync, bool is_migrate, bool is_local)
+ {
+ 	schedstat_inc(p, se.nr_wakeups);
+ 	if (is_sync)
+ 		schedstat_inc(p, se.nr_wakeups_sync);
+ 	if (is_migrate)
+ 		schedstat_inc(p, se.nr_wakeups_migrate);
+ 	if (is_local)
+ 		schedstat_inc(p, se.nr_wakeups_local);
+ 	else
+ 		schedstat_inc(p, se.nr_wakeups_remote);
+ 
+ 	activate_task(rq, p, 1);
+ 
+ 	/*
+ 	 * Only attribute actual wakeups done by this task.
+ 	 */
+ 	if (!in_interrupt()) {
+ 		struct sched_entity *se = &current->se;
+ 		u64 sample = se->sum_exec_runtime;
+ 
+ 		if (se->last_wakeup)
+ 			sample -= se->last_wakeup;
+ 		else
+ 			sample -= se->start_runtime;
+ 		update_avg(&se->avg_wakeup, sample);
+ 
+ 		se->last_wakeup = se->sum_exec_runtime;
+ 	}
+ }
+ 
+ static inline void ttwu_woken_up(struct task_struct *p, struct rq *rq,
+ 				 int wake_flags, bool success)
+ {
+ 	trace_sched_wakeup(rq, p, success);
+ 	check_preempt_curr(rq, p, wake_flags);
+ 
+ 	p->state = TASK_RUNNING;
+ #ifdef CONFIG_SMP
+ 	if (p->sched_class->task_wake_up)
+ 		p->sched_class->task_wake_up(rq, p);
++
++	if (unlikely(rq->idle_stamp)) {
++		u64 delta = rq->clock - rq->idle_stamp;
++		u64 max = 2*sysctl_sched_migration_cost;
++
++		if (delta > max)
++			rq->avg_idle = max;
++		else
++			update_avg(&rq->avg_idle, delta);
++		rq->idle_stamp = 0;
++	}
+ #endif
+ 	/*
+ 	 * Wake up is complete, fire wake up notifier.  This allows
+ 	 * try_to_wake_up_local() to be called from wake up notifiers.
+ 	 */
+ 	if (success)
+ 		fire_sched_notifier(p, wakeup);
+ }
+ 
+ /**
   * try_to_wake_up - wake up a thread
   * @p: the to-be-woken-up thread
   * @state: the mask of task states that can be woken

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Ingo Molnar]

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

> Hi Tejun,
> 
> Today's linux-next merge of the workqueues tree got a conflict in
> kernel/sched.c between commit eae0c9dfb534cb3449888b9601228efa6480fdb5
> ("sched: Fix and clean up rate-limit newidle code") from the tip tree and
> commit 710c15b748f5ce9c573cc047f419cf007a677a9a ("sched: refactor
> try_to_wake_up() and implement try_to_wake_up_local()") from the
> workqueues tree.

Tejun,

Please submit scheduler patches to the scheduler tree. Such level of 
refactoring of a critical scheduler component needs to go through the 
regular scheduler channels. This is a frequently modified piece of code 
and conflicts are likely in the future.

Thanks,

	Ingo

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Tejun Heo]

11/26/2009 05:12 PM, Ingo Molnar wrote:
> Please submit scheduler patches to the scheduler tree. Such level of 
> refactoring of a critical scheduler component needs to go through the 
> regular scheduler channels. This is a frequently modified piece of code 
> and conflicts are likely in the future.

Sure, which sched/* branch should I base these patches on?
Alternatively, pulling the following branch into one of sched/* should
do the trick too.

 git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq.git for-sched

Thanks.

-- 
tejun

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Ingo Molnar]

* Tejun Heo <tj@kernel.org> wrote:

> 11/26/2009 05:12 PM, Ingo Molnar wrote:
> > Please submit scheduler patches to the scheduler tree. Such level of 
> > refactoring of a critical scheduler component needs to go through the 
> > regular scheduler channels. This is a frequently modified piece of code 
> > and conflicts are likely in the future.
> 
> Sure, which sched/* branch should I base these patches on?

You could send the patch you rely on standalone (it seems to be a single 
patch) and we can look at applying it to the scheduler tree. That 
reduces the conflicts on an ongoing basis. Please Cc: PeterZ and Mike 
Galbraith as well.

Thanks,

	Ingo

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Tejun Heo]

Hello, Ingo.

11/26/2009 06:26 PM, Ingo Molnar wrote:
>> Sure, which sched/* branch should I base these patches on?
> 
> You could send the patch you rely on standalone (it seems to be a single 
> patch) and we can look at applying it to the scheduler tree. That 
> reduces the conflicts on an ongoing basis. Please Cc: PeterZ and Mike 
> Galbraith as well.

The tree contains four scheduler patches.

0001-sched-rename-preempt_notifier-to-sched_notifier-and-.patch
0002-sched-update-sched_notifier-and-add-wakeup-sleep-not.patch
0003-sched-implement-sched_notifier_wake_up_process.patch
0004-sched-implement-force_cpus_allowed.patch

1, 2 and 4 are somewhat spread throughout sched.c so it would be
better if they all are routed through sched tree.  Currently the
wq#for-sched contains the followings on top of linus#master.

* Adds debugobj support to workqueue.

* Pulls in sched/urgent to receive the scheduler fix.

* Adds the above four patches.

If pulling in from the existing branch is an option, I'd prefer that.
If not, please let me know.  I'll send the above four patches against
sched/urgent.

Thanks.

-- 
tejun

Re: linux-next: manual merge of the workqueues tree with the tip tree

[Ingo Molnar]

* Tejun Heo <tj@kernel.org> wrote:

> Hello, Ingo.
> 
> 11/26/2009 06:26 PM, Ingo Molnar wrote:
> >> Sure, which sched/* branch should I base these patches on?
> > 
> > You could send the patch you rely on standalone (it seems to be a single 
> > patch) and we can look at applying it to the scheduler tree. That 
> > reduces the conflicts on an ongoing basis. Please Cc: PeterZ and Mike 
> > Galbraith as well.
> 
> The tree contains four scheduler patches.
> 
> 0001-sched-rename-preempt_notifier-to-sched_notifier-and-.patch
> 0002-sched-update-sched_notifier-and-add-wakeup-sleep-not.patch
> 0003-sched-implement-sched_notifier_wake_up_process.patch
> 0004-sched-implement-force_cpus_allowed.patch
> 
> 1, 2 and 4 are somewhat spread throughout sched.c so it would be
> better if they all are routed through sched tree.  Currently the
> wq#for-sched contains the followings on top of linus#master.
> 
> * Adds debugobj support to workqueue.
> 
> * Pulls in sched/urgent to receive the scheduler fix.
> 
> * Adds the above four patches.
> 
> If pulling in from the existing branch is an option, I'd prefer that. 
> If not, please let me know.  I'll send the above four patches against 
> sched/urgent.

I've merged sched/urgent into sched/core and pushed it out - mind basing 
any sched.c patches on top of that and send a series of scheduler-only 
patches?

Thanks,

	Ingo