Re: 2.5.74-mm1

[Mike Galbraith <efault@gmx.de>]

At 07:47 AM 7/7/2003 -0700, Davide Libenzi wrote:
>On Mon, 7 Jul 2003, Mel Gorman wrote:
>
> > On Mon, 7 Jul 2003, Daniel Phillips wrote:
> >
> > > And set up distros to grant it by default.  Yes.
> > >
> > > The problem I see is that it lets user space priorities invade the 
> range of
> > > priorities used by root processes.
> >
> > That is the main drawback all right but it could be addressed by having a
> > CAP_SYS_USERNICE capability which allows a user to renice only their own
> > processes to a highest priority of -5, or some other reasonable value
> > that wouldn't interfere with root processes. This capability would only be
> > for applications like music players which need to give hints to the
> > scheduler.
>
>The scheduler has to work w/out external input, period. If it doesn't we
>have to fix it and not to force the user to submit external hints.

What about internal hints?

Fishing expedition:

I'm tinkering with Linus' backboost trick, and what I'd like to try is 
filtering out things which are doing I/O to graphics card, sound card, 
mouse, kdb... whatnot with an in_interactive_interrupt().  Before I go off 
tilting at that windmill, do you (or anyone) know of any reason why that 
would be either stupid or impossible?

Right now, I've got backboost max cpu consumption restricted, max priority 
restricted /proc enabled and /proc tweakable, but I need to further 
restrict/focus it somehow.  Any ideas wrt taming/focusing the little 
beastie would be appreciated.  I'd really like to get it tame enough to be 
reconsidered...

I like backboost for the desktop quite a bit. Take xmms for instance, fire 
it up and turn on it's cpu-hog-and-a-half gl visualization.  The sound 
thread runs at high priority due to low cpu usage.  The gl thread otoh is 
down in the mud, and is instantly disturbed by background tasks who 
unreasonably ;) want their fair share of cpu.  With backboost, the gl 
thread is boosted above background stuff where he belongs, the whole point 
of interactivity being that it's not only ok to be grossly unfair about 
things a human being is connecting to, it's a goodthing(tm)... worker can 
stare mindlessly at glitz and listen to skip free music while his 
employer's code gets moldy instead of being compiled. ;-)

Neat thing about backboost is that when you cover the gl thread, it 
automagically loses boost, so when unreasonable boss walks in and you cover 
it up, the compile speeds back up.  The glitz thread is only interactive if 
you can see it, and does in fact only receive boost when you can see 
it.  That's pretty cool.

         -Mike