On 9/18/12, Andriy Gapon <a...@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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
