lkml.org 
[lkml]   [2017]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.
From
Date
On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote:
> Hello, Atish, Peter, all.
>
> I have a question about if a task's nr_cpus_allowed is 1.
> In that scenario we do not call select_task_rq. Therefore
> even thought a task "p" is placed on idle CPU that CPU
> will not be marked as claimed for wake-up.
>
> What do you think about adding per_cpu(claim_wakeup, cpu) = 1;
> to select_task_rq() instead and possibly get rid of them from
> other places (increases a race window a bit)?

My thoughts on all of this is that we need less SIS, not more.  Rather
than trying so hard for the absolute lowest wakeup latency, which
induces throughput/efficiency robbing bouncing, I think we'd be better
of considering leaving an already llc affine task where it is if the
average cycle time is sufficiently low that it will likely hit the CPU
RSN.  Completely ignoring low utilization kernel threads would go a
long way to getting rid of bouncing userspace (which tends to have a
meaningful footprint), all over hell and creation.

You could also periodically send mobile kthreads down the slow path to
try to keep them the hell away from partially busy CPUs, as well as
anything else that hasn't run for a while, to keep background cruft
from continually injecting itself into the middle of a cross core
cyber-sex.

-Mike

\
 
 \ /
  Last update: 2017-11-23 14:15    [W:0.101 / U:0.708 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site