> > > The only reason I added quantum, was that I stumbled on the round robin > > > interval buglet. Initially added a fixed 100 ms per proc, and then > > > decided how much I could explore this quantum idea while still trying to > > > keep the code understandable. > > > > Which buglet? Should we fix it? > > A minimal diff for the round robin interval buglet is attached at the end of > this email, doesn't use the SCHED_LOCK(). Note, I removed all the different > quantums, just kept it at the default 100 ms, to try to convey and determine > if it is my misunderstanding, and there is no buglet. I still haven't looked > deeply at implementing the sysctl for a separate systat view. Also, your > diffs to minimize SCHED_LOCK() contention, makes me think it is not right > time to introduce variable rr interval scheduling, without trying to reduce > the simple cases of SCHED_LOCK() contention first.
Aaaaaand, I forgot to give an explanation in the email about this diff. Currently, because of the 100 ms round-robin, we don't know when a proc actually started, it might have started 10 ms or 20 ms ago, and suddenly it could be moved away due to the rrticks being hit every 100 ms, that rr interval clock and the proc start time is never guaranteed to be in sync. We try to give a proc its full quantum of 100 ms, once it completes its 100 ms quantum, then it signals yield, and lets other proc's run. The other kernel mechanisms are not touched at all. So a running proc could get preempted via sched_pause(), and everytime any proc runs, its quantum is reset back to 10 rrticks_init. In best case, each proc gets 100 ms of running time, which is an improvement over the current behavoir. In the worst case, a proc could get preempted/yield to higher priority proc, but this worst case behaviour is the same before and after this diff. Thanks
