On Mon, Oct 29, 2012 at 6:59 PM, Attilio Rao <atti...@freebsd.org> wrote:
[ trimm ] > This also let me wonder about the tdq_lowpri check in the self case, > in general. Basically it forces sched_pickcpu() to select self if and > only if the new thread to schedule has an higher priority than the > lowest one on curcpu. Why is that like this? Exactly this check is > used to enforce some sort of fairness? > It would be good if Jeff spends a word or two on this check specifically. Also, I've read the code of tdq_setlowpri() more closely and I think the name tdq_lowpri is highly misleading, because that seems to me the *highest* priority thread that gets returned. Said that, this means that self will be selected in sched_pickcpu() if and only if the new thread has an higher priority than all the ones on the self runqueue. Isn't all this a bit too extreme? Assuming that one cpu has only a single high-priority thread and others are very loaded it would likely make sense to not keep loading them but switch to the self one, maybe. > Anyway the patch that implements what suggested, let me know your > thinking about it: > http://www.freebsd.org/~attilio/avg_ule2.patch I was thinking that however, maybe we could do the tdq_choose() calculation if self == target, to have a little more chances to get the optimization in place, eventually. 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"