Messages in this thread | | | Subject | Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window. | From | Mike Galbraith <> | Date | Thu, 23 Nov 2017 14:13:01 +0100 |
| |
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
| |