Re: [PATCH] O13int for interactivity

[Mike Galbraith]

At 12:51 PM 8/12/2003 +1000, Nick Piggin wrote:


> Rob Landley wrote:
>
> > On Tuesday 05 August 2003 06:32, Nick Piggin wrote:
> >
> >
> > > But by employing the kernel's services in the shape of a blocking
> > > syscall, all sleeps are intentional.
> >
> > Wrong.  Some sleeps indicate "I have run out of stuff to do right now, 
> > I'm going to wait for a timer or another process or something to wake me 
> > up with new work".
> >
> >
> >
> > Some sleeps indicate "ideally this would run on an enormous ramdisk 
> > attached to gigabit ethernet, but hard drives and internet connections 
> > are just too slow so my true CPU-hogness is hidden by the fact I'm 
> > running on a PC instead of a mainframe."
>
> I don't quite understand what you are getting at, but if you don't want to
> sleep you should be able to use a non blocking syscall. But in some cases
> I think there are times when you may not be able to use a non blocking call.
> And if a process is a CPU hog, its a CPU hog. If its not its not. Doesn't
> matter how it would behave on another system.

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.

        -Mike 

-
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/