Re: [PATCH] O13int for interactivity
From: Mike Galbraith
Date: Tue Aug 12 2003 - 01:16:55 EST
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/