lkml.org 
[lkml]   [2020]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC PATCH 0/3] newidle_balance() latency mitigation
Date

On 30/04/20 13:42, Vincent Guittot wrote:
>> >> Random thought that just occurred to me; in the grand scheme of things,
>> >> with something in the same spirit as task-stealing (i.e. don't bother with
>> >> a full fledged balance at newidle, just pick one spare task somewhere),
>> >> none of this would be required.
>> >
>> > newly idle load balance already stops after picking 1 task
>>
>> Mph, I had already forgotten your changes there. Is that really always the
>> case for newidle? In e.g. the busiest->group_type == group_fully_busy case,
>> I think we can pull more than one task.
>
> for newly_idle load balance, detach_tasks stops after finding 1 suitable task
>

Right, I hadn't noticed

7e96fa5875d4 ("sched: pull only one task during NEWIDLE balancing to limit critical section")

>>
>> > Now if your proposal is to pick one random task on one random cpu, I'm
>> > clearly not sure that's a good idea
>> >
>>
>> IIRC Steve's implementation was to "simply" pull one task from any CPU
>> within the LLC domain that had > 1 runnable tasks. I quite like this since
>> picking any one task is almost always better than switching to the idle
>> task, but it wasn't a complete newidle_balance() replacement just yet.
>>
>> >
>> >>
>> >> Sadly I don't think anyone has been looking at it any recently.

\
 
 \ /
  Last update: 2020-04-30 15:56    [W:0.063 / U:3.984 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site