Messages in this thread | | | Date | Wed, 21 Mar 2007 18:24:11 +0100 | From | Artur Skawina <> | Subject | Re: RSDL v0.31 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |