Re: [PATCH] O13int for interactivity

[Nick Piggin]

Mike Galbraith wrote:

> At 05:07 PM 8/12/2003 +1000, Nick Piggin wrote:
>
>
> > Mike Galbraith wrote:

snip

> > > Ah, but there is something there.  Take the X and xmms's gl thread 
> > > thingy I posted a while back.  (X runs long enough to expire in the 
> > > presence of a couple of low priority cpu hogs.  gl thread, which is 
> > > a mondo cpu hog, and normally runs and runs and runs at cpu hog 
> > > priority, suddenly acquires extreme interactive priority, and X, 
> > > which is normally sleepy suddenly becomes permanently runnable at 
> > > cpu hog priority)  The gl thread starts sleeping because X isn't 
> > > getting enough cpu to be able to get it's work done and go to 
> > > sleep.  The gl thread isn't voluntarily sleeping, and X isn't 
> > > voluntarily running.
> > > The behavior change is forced upon both.
> >
> >
> >
> > It does... It is I tell ya!
> >
> > Look, the gl thread is probably _very_ explicitly asking to sleep. No I
> > don't know how X works, but I have an idea that select is generally used
> > as an event notification, right?
>
>
> Oh, sure, it blocks because it asks for it... but not because it 
> _wants_ to :)  It wants to create work for X fast enough to make a 
> nice stutter free bit of eye-candy.


Well if it doesn't want to, it could just give select a timeout of 0 though.

> > Now the gl thread is essentially saying "wait until X finishes the work
> > I've given it, or I get some other event": ie. "put me to sleep until
> > this fd becomes readable".
>
>
> Yes.  Voluntary or involuntary is just a matter of point of view.


Well I would think a NULL, or non-zero timeout would mean its a voluntary
sleep. If the thread has nothing to do until there is an event on the fd,
then it really does want to sleep.

Anyway, this whole thread arose because Con was making the scheduler do
different things for interruptible and uninterruptible sleeps which I
didn't think was a very good idea. Con thought uninterruptible implied
involuntary sleep (though there might have been some confusion).

I don't think they should be treated any differently, but hey I'm not
making any code or having any problems! Just trying to stir the pot a
bit!

> > OK maybe your scenario is a big problem. Its not due to any imagined
> > semantics in the way things are sleeping. Its due to the scheduler.
>
>
> It's due to the scheduler to a point... only in that it doesn't 
> recognize the problem and correct it (that might be pretty hard to 
> do).  If my hardware were fast enough that X could get the work done 
> in the allotted time, the problem wouldn't arise in the first place.  
> I bet it's fairly hard to reproduce on a really fast box.  It happens 
> easily on my box because the combination of X and the gl thread need 
> most of what my hardware has to offer.

I think backboost was very nice. I'd say Con could probably get a lot
further if that was in but its not going to happen now.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/