[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.025 / U:59.504 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site