ule+smp: small optimization for turnstile priority lending

[Attilio Rao]

On 9/18/12, Andriy Gapon <avg at freebsd.org> wrote:
>
> Here is a snippet that demonstrates the issue on a supposedly fully loaded
> 2-processor system:
>
> 136794   0 3670427870244462 KTRGRAPH group:"thread", id:"Xorg tid 102818",
> state:"running", attributes: prio:122
>
> 136793   0 3670427870241000 KTRGRAPH group:"thread", id:"cc1plus tid
> 111916",
> state:"yielding", attributes: prio:183, wmesg:"(null)", lockname:"(null)"
>
> 136792   1 3670427870240829 KTRGRAPH group:"thread", id:"idle: cpu1 tid
> 100004",
> state:"running", attributes: prio:255
>
> 136791   1 3670427870239520 KTRGRAPH group:"load", id:"CPU 1 load",
> counter:0,
> attributes: none
>
> 136790   1 3670427870239248 KTRGRAPH group:"thread", id:"firefox tid
> 113473",
> state:"blocked", attributes: prio:122, wmesg:"(null)", lockname:"unp_mtx"
>
> 136789   1 3670427870237697 KTRGRAPH group:"load", id:"CPU 0 load",
> counter:2,
> attributes: none
>
> 136788   1 3670427870236394 KTRGRAPH group:"thread", id:"firefox tid
> 113473",
> point:"wokeup", attributes: linkedto:"Xorg tid 102818"
>
> 136787   1 3670427870236145 KTRGRAPH group:"thread", id:"Xorg tid 102818",
> state:"runq add", attributes: prio:122, linkedto:"firefox tid 113473"
>
> 136786   1 3670427870235981 KTRGRAPH group:"load", id:"CPU 1 load",
> counter:1,
> attributes: none
>
> 136785   1 3670427870235707 KTRGRAPH group:"thread", id:"Xorg tid 102818",
> state:"runq rem", attributes: prio:176
>
> 136784   1 3670427870235423 KTRGRAPH group:"thread", id:"Xorg tid 102818",
> point:"prio", attributes: prio:176, new prio:122, linkedto:"firefox tid
> 113473"
>
> 136783   1 3670427870202392 KTRGRAPH group:"thread", id:"firefox tid
> 113473",
> state:"running", attributes: prio:104
>
> See how how the Xorg thread was forced from CPU 1 to CPU 0 where it
> preempted
> cc1plus thread (I do have preemption enabled) only to leave CPU 1 with zero
> load.

I think that the idea is bright, but I have reservations against the
implementation because it seems to me there are too many layering
violations.

What is suggest is somewhat summarized like that:
- Add a new SRQ_WILLSLEEP or the name you prefer
- Add a new "flags" argument to sched_lend_prio() (both ule and 4bsd)
and sched_thread_priority (ule only)
- sched_thread_priority() will pass down the new flag to sched_add()
which passed down to sched_pickcpu().

This way sched_pickcpu() has the correct knowledge of what is going on
and it can make the right decision. You likely don't need to lower the
tdq_load at that time either this way, because sched_pickcpu() can
just adjust it locally for its decision.

What do you think?

Thanks,
Attilio


-- 
Peace can only be achieved by understanding - A. Einstein