[lkml]   [2003]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] O13int for interactivity
On Monday 11 August 2003 22:51, 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.

So you can then block on poll instead, you mean?

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

Audio playback, video playback, animated gifs in your web browser, and even
first person shooters have built in rate limiting. (Okay, games can go to an
insanely high framerate, but usually they achieve "good enough" and are happy
with that unless you're doing a benchmark with them.)

There is a certain rate of work they do, and if they can manage that they stop
working. On a system with twice as much CPU power and disks twice as fast,
kmail shouldn't use significantly more CPU keeping up with my typing. These
are "interactive" tasks.

Bug gzip, tar, gcc, and most cron jobs, are a different type of task. They
have nobuilt-in rate limiting. On a system with twice as much CPU and disks
twice as fast, they finish twice as quickly. They never voluntarily go idle
until they exit; when they're idle it just means they hit a bottleneck. The
system can never be "fast enough" that these quiesce themselves for a while
because they've run out of work just now.

These are hogs, often both of CPU time and I/O bandwidth. Being blocked on
I/O does not stop them from being hogs, it just means they're juggling their

An mpeg player has times when it's neither blocked on CPU or on I/O, it's
waiting until it's time to display the next frame.

Now some of this could be viewed as a spooler problem, where there's a slow
output device (the screen, the sound card, etc) and if you wanted to you
could precompute stuff into a big memory wasting buffer and then instead of
skipping because you're not getting scheduled fast enough you're skipping
because your precomputed buffer got swapped to disk. But the difference here
is that xmms or xine could do their output generation much faster than they
are, if they wanted to. The output device could be sped up. Your animated
gif can cycle too fast to see, you can fast-forward through your movie, you
can play an mpeg so it sounds like chip and dale on helium... But they
don't, they intentionally rate limit the output, and what they want in return
is low latency when the rate limiting is up.

When you're rate limiting the output, you want to accurately control the rate.
You don't want it to be too fast (timers are great at this), and you don't
want it to be too slow (you get skips or miss frames).

That's what Con's detecting. It's a heuristic. But it's a good heuristic. A
process that plays nice and yields the CPU regularly gets a priority boost.
(That's always BEEN a heuristic.)

The current scheduler code has moved a bit beyond this, but this is the bit I
was talking about when I disagreed with you earlier.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:47    [W:0.110 / U:0.440 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site