Re: [PATCH v4 5/6] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()

2014-08-12 Thread Kirill Tkhai
В Вт, 12/08/2014 в 11:22 +0200, Peter Zijlstra пишет: > Something like so? Pair brackets detach_one_task()/attach_one_task() look good. No objections. > --- > Subject: sched/fair: Remove double_lock_balance() from > active_load_balance_cpu_stop() > From: Kirill Tkhai > Date: Wed, 6 Aug 2014 12:

Re: [PATCH v4 5/6] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()

2014-08-12 Thread Peter Zijlstra
Something like so? --- Subject: sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop() From: Kirill Tkhai Date: Wed, 6 Aug 2014 12:06:56 +0400 Avoid double_rq_lock() and use ONRQ_MIGRATING for active_load_balance_cpu_stop(). The advantage is (obviously) not holding two 'r

Re: [PATCH v4 5/6] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()

2014-08-12 Thread Peter Zijlstra
On Wed, Aug 06, 2014 at 12:06:56PM +0400, Kirill Tkhai wrote: > > Bad situation: > > double_lock_balance() drops busiest_rq lock. The busiest_rq is *busiest*, > and a lot of tasks and context switches there. We are dropping the lock > and waiting for it again. > > Let's just detach the task and

[PATCH v4 5/6] sched/fair: Remove double_lock_balance() from active_load_balance_cpu_stop()

2014-08-06 Thread Kirill Tkhai
Bad situation: double_lock_balance() drops busiest_rq lock. The busiest_rq is *busiest*, and a lot of tasks and context switches there. We are dropping the lock and waiting for it again. Let's just detach the task and once finally unlock it! Warning: this admits unlocked using of can_migrate_ta