Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Byungchul Park
On Wed, Nov 18, 2015 at 12:55:10AM +0100, Peter Zijlstra wrote: > On Wed, Nov 18, 2015 at 08:37:00AM +0900, Byungchul Park wrote: > > > Which one do you think to be fixed? The one above migrate_task_rq_fair()? > > I wonder if it would be ok even it does not hold pi_lock in > >

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Peter Zijlstra
On Wed, Nov 18, 2015 at 08:37:00AM +0900, Byungchul Park wrote: > Which one do you think to be fixed? The one above migrate_task_rq_fair()? > I wonder if it would be ok even it does not hold pi_lock in > migrate_task_rq_fair(). If you say *no problem*, I will try to fix the > comment. The one

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Byungchul Park
On Tue, Nov 17, 2015 at 12:21:49PM +0100, Peter Zijlstra wrote: > > Looks that way, I'm not sure we always hold pi_lock there. But I'm low > on sleep, so I could have overlooked something. > > See for example move_queued_task(), we call set_task_cpu() with rq->lock > held, but no pi_lock.

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Peter Zijlstra
On Tue, Nov 17, 2015 at 09:44:16AM +0900, Byungchul Park wrote: > > So currently, set_task_cpu() is serialized by: > > > > - p->pi_lock; on wakeup > > - rq->lock; otherwise > > > > (see the #ifdef CONFIG_LOCKDEP comment in set_task_cpu()) > > I already read the comment.. Then do you mean the

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Peter Zijlstra
On Tue, Nov 17, 2015 at 09:44:16AM +0900, Byungchul Park wrote: > > So currently, set_task_cpu() is serialized by: > > > > - p->pi_lock; on wakeup > > - rq->lock; otherwise > > > > (see the #ifdef CONFIG_LOCKDEP comment in set_task_cpu()) > > I already read the comment.. Then do you mean the

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Peter Zijlstra
On Wed, Nov 18, 2015 at 08:37:00AM +0900, Byungchul Park wrote: > Which one do you think to be fixed? The one above migrate_task_rq_fair()? > I wonder if it would be ok even it does not hold pi_lock in > migrate_task_rq_fair(). If you say *no problem*, I will try to fix the > comment. The one

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Byungchul Park
On Wed, Nov 18, 2015 at 12:55:10AM +0100, Peter Zijlstra wrote: > On Wed, Nov 18, 2015 at 08:37:00AM +0900, Byungchul Park wrote: > > > Which one do you think to be fixed? The one above migrate_task_rq_fair()? > > I wonder if it would be ok even it does not hold pi_lock in > >

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-17 Thread Byungchul Park
On Tue, Nov 17, 2015 at 12:21:49PM +0100, Peter Zijlstra wrote: > > Looks that way, I'm not sure we always hold pi_lock there. But I'm low > on sleep, so I could have overlooked something. > > See for example move_queued_task(), we call set_task_cpu() with rq->lock > held, but no pi_lock.

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-16 Thread Byungchul Park
On Mon, Nov 16, 2015 at 01:53:51PM +0100, Peter Zijlstra wrote: > On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > > So the problem is that as soon as that ->cpu store comes through, the > > > other rq->lock can

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-16 Thread Peter Zijlstra
On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > So the problem is that as soon as that ->cpu store comes through, the > > other rq->lock can happen, even though we might still hold a rq->lock > > thinking we're

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-16 Thread Peter Zijlstra
On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > So the problem is that as soon as that ->cpu store comes through, the > > other rq->lock can happen, even though we might still hold a rq->lock > > thinking we're

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-16 Thread Byungchul Park
On Mon, Nov 16, 2015 at 01:53:51PM +0100, Peter Zijlstra wrote: > On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > > So the problem is that as soon as that ->cpu store comes through, the > > > other rq->lock can

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-11 Thread Byungchul Park
On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > > > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > > > On Sat, Oct 24, 2015

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-11 Thread Byungchul Park
On Wed, Nov 11, 2015 at 08:51:47AM +0900, Byungchul Park wrote: > On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > > On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > > > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > > > On Sat, Oct 24, 2015

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-10 Thread Byungchul Park
On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > > > +++

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-10 Thread Peter Zijlstra
On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > > +++ b/kernel/sched/core.c > > > @@ -1264,6 +1264,8 @@

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-10 Thread Byungchul Park
On Tue, Nov 10, 2015 at 01:16:47PM +0100, Peter Zijlstra wrote: > On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > > > +++

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-10 Thread Peter Zijlstra
On Tue, Nov 10, 2015 at 10:09:05AM +0900, Byungchul Park wrote: > On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > > +++ b/kernel/sched/core.c > > > @@ -1264,6 +1264,8 @@

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-09 Thread Byungchul Park
On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > +++ b/kernel/sched/core.c > > @@ -1264,6 +1264,8 @@ EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr); > > > > void set_task_cpu(struct task_struct *p, unsigned

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-09 Thread Peter Zijlstra
On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > +++ b/kernel/sched/core.c > @@ -1264,6 +1264,8 @@ EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr); > > void set_task_cpu(struct task_struct *p, unsigned int new_cpu) > { > + unsigned int prev_cpu = task_cpu(p); > + > #ifdef

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-09 Thread Peter Zijlstra
On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > +++ b/kernel/sched/core.c > @@ -1264,6 +1264,8 @@ EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr); > > void set_task_cpu(struct task_struct *p, unsigned int new_cpu) > { > + unsigned int prev_cpu = task_cpu(p); > + > #ifdef

Re: [PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-11-09 Thread Byungchul Park
On Mon, Nov 09, 2015 at 02:29:14PM +0100, Peter Zijlstra wrote: > On Sat, Oct 24, 2015 at 01:16:21AM +0900, byungchul.p...@lge.com wrote: > > +++ b/kernel/sched/core.c > > @@ -1264,6 +1264,8 @@ EXPORT_SYMBOL_GPL(set_cpus_allowed_ptr); > > > > void set_task_cpu(struct task_struct *p, unsigned

[PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-10-23 Thread byungchul.park
From: Byungchul Park the "sched/fair: make it possible to account fair load avg consistently" patch makes rmb() and updating last_update_time called twice when doing a migration, which can be negative at performance. actually we can optimize it by omiting the updating part of

[PATCH v4 3/3] sched: optimize migration by forcing rmb() and updating to be called once

2015-10-23 Thread byungchul.park
From: Byungchul Park the "sched/fair: make it possible to account fair load avg consistently" patch makes rmb() and updating last_update_time called twice when doing a migration, which can be negative at performance. actually we can optimize it by omiting the updating