Re: [PATCH v4 08/10] sched/fair: Steal work from an overloaded CPU when CPU goes idle

[Steven Sistare]

On 12/7/2018 3:21 PM, Valentin Schneider wrote:
> Hi Steve,
> 
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -6778,20 +6791,22 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_
>>  	update_misfit_status(NULL, rq);
>>  
>>  	/*
>> -	 * We must set idle_stamp _before_ calling idle_balance(), such that we
>> -	 * measure the duration of idle_balance() as idle time.
>> +	 * We must set idle_stamp _before_ calling try_steal() or
>> +	 * idle_balance(), such that we measure the duration as idle time.
>>  	 */
>>  	rq_idle_stamp_update(rq); 
> 
> idle_balance() has a
> 
> 	/*
> 	 * Do not pull tasks towards !active CPUs...
> 	 */
> 	if (!cpu_active(this_cpu))
> 		return 0;
> 
> check which we probably want for stealing too, so we could hoist it up here
> to cover both idle_balance() and try_steal().

try_steal() already checks cpu_active.  I could hoist it.

- Steve

> 
>>  	new_tasks = idle_balance(rq, rf);
>> +	if (new_tasks == 0)
>> +		new_tasks = try_steal(rq, rf);
>>  
>>  	if (new_tasks)
>>  		rq_idle_stamp_clear(rq);
>>  
>>  	/*
>> -	 * Because idle_balance() releases (and re-acquires) rq->lock, it is
>> -	 * possible for any higher priority task to appear. In that case we
>> -	 * must re-start the pick_next_entity() loop.
>> +	 * Because try_steal() and idle_balance() release (and re-acquire)
>> +	 * rq->lock, it is possible for any higher priority task to appear.
>> +	 * In that case we must re-start the pick_next_entity() loop.
>>  	 */
>>  	if (new_tasks < 0)
>>  		return RETRY_TASK;
> [...]
>