On Thu, 19 Apr 2007, Mike Galbraith wrote:
> On Thu, 2007-04-19 at 09:09 +0200, Ingo Molnar wrote:
> > * Mike Galbraith <[EMAIL PROTECTED]> wrote:
> >
> > > With a heavily reniced X (perfectly fine), that should indeed solve my
> > > daily usage pattern nicely (always need godmode for shells, but not
> > > for mozilla and ilk. 50/50 split automatic without renice of entire
> > > gui)
> >
> > how about the first-approximation solution i suggested in the previous
> > mail: to add a per UID default nice level? (With this default defaulting
> > to '-10' for all root-owned processes, and defaulting to '0' for
> > everything else.) That would solve most of the current CFS regressions
> > at hand.
>
> That would make my kernel builds etc interfere with my other self's
> surfing and whatnot. With it by EUID, when I'm surfing or whatnot, the
> X portion of my Joe-User activity pushes the compile portion of root
> down in bandwidth utilization automagically, which is exactly the right
> thing, because the root me in not as important as the Joe-User me using
> the GUI at that time. If the idea of X disturbing root upsets some,
> they can move X to another UID. Generally, it seems perfect for here.
Now guys, I did not follow the whole lengthy and feisty thread, but IIRC
Con's scheduler has been attacked because, among other argouments, was
requiring X to be reniced. This happened like a month ago IINM.
I did not have time to look at Con's scheduler, and I only had a brief
look at Ingo's one (looks very promising IMO, but so was the initial O(1)
post before all the corner-cases fixes went in).
But this is not a about technical merit, this is about applying the same
rules of judgement to others as well to ourselves.
We went from a "renicing X to -10 is bad because the scheduler should
be able to correctly handle the problem w/out additional external plugs"
to a totally opposite "let's renice -10 X, the whole SCHED_NORMAL kthreads
class, on top of all the tasks owned by root" [1].
>From a spectator POV like myself in this case, this looks rather "unfair".
[1] I think, before and now, that that's more a duck tape patch than a
real solution. OTOH if the "solution" is gonna be another maze of
macros and heuristics filled with pretty bad corner cases, I may
prefer the former.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
