On 2017/11/23 10:00 AM, Josef Bacik wrote:
On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote:
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.
And on this thanksgiving I'm thankful for Mike, and his entertaining early
morning emails.
:) :).
Josef
