Re: RSDL v0.31

[Artur Skawina <art_k@o2.pl>]

Al Boldi wrote:
> Artur Skawina wrote:
>> Al Boldi wrote:
>>> -	p->quota = rr_quota(p);
>>> +	/*
>>> +	 * boost factor hardcoded to 5; adjust to your liking
>>> +	 * higher means more likely to DoS
>>> +	 */
>>> +	p->quota = rr_quota(p) + (((now - p->timestamp) >> 20) * 5);

>> mouse cursor stalls lasting almost 1s. i/o bound tasks starving X?
>> After reverting the patch everything is smooth again.
> 
> This patch wasn't really meant for production, as any sleeping background 
> proc turned cpu-hog may DoS the system.
> 
> If you like to play with this, then you probably want to at least reset the 
> quota in its expiration.

well, the problem is that i can't reproduce the problem :) I tried
the patch because i suspected it could introduce regressions, and it
did. Maybe with some tuning a reasonable compromise could be found,
but first we need to know what to tune for... Does anybody have a
simple reproducible way to show the scheduling regressions of RSDL
vs mainline? ie one that does not involve (or at least is
independent of) specific X drivers, binary apps etc. Some reports
mentioned MP, is UP less susceptible?

I've now tried a -j2 kernel compilation on UP and in the not niced
case X interactivity suffers, which i guess is to be expected when
you have ~5 processes competing for one cpu (2*(cc+as)+X). "nice -5"
helps a bit, but does not eliminate the effect completely. Obviously
the right solution is to nice the makes, but i think the scheduler
could do better, at least in the case of almost idle X (once you
start moving windows etc it becomes a cpuhog just as the the
compiler). I'll look into this, maybe there's a way to prioritize
often sleeping tasks which can not be abused.
Another thing is the nice levels; right now "nice -10" means ~35%
and "nice -19" gives ~5% cpu; that's probably 2..5 times too much.

artur