[lkml]   [2003]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectO(1) scheduler & interactivity improvements
    Hi all,

    I must say I'm a little bit disappointed with the interactive feeling of
    latest kernels. From what I have read, it seems the scheduler decides on
    the "interactive" behavior of a process based on its CPU usage and
    sleeping times. I am no kernel expert, so I will assume this is how it
    works, more or less, behind the scenes.

    I think that marking a process as "interactive" based on the previous
    premise is quite unreal. Let's take, for example, a real application
    like a word processor which performs background spell checking. The word
    processor should be considered interactive, even when it may be hogging
    the CPU a lot to perform the background spell check and the rest of its
    threads are sleeping waiting for user input.

    As someone said before in the list, a process should be marked
    "interactive" based on the fact that it's receiving user input, for
    example, key strokes, mouse movements or any events received from any
    input device, not based on its CPU usage. I think applications like XMMS
    or mplayer shouldn't be considered interactive (at least, not until they
    start interacting with user), and they have a constant usage of CPU.
    However, interactive applications have peaks, requiring shots of CPU for
    very short times. However, that's not necessarily true, as I said before
    with the example of the word processor: it could well be wasting 100% of
    CPU to perform spellchecking but it should still be considered an
    interactive application: a single user keystroke should take preference
    over the background spellchecking.

    For terminal based, interactive applications (like pine, vi, and
    company), which are connected to tty devices, a user input event could
    make the scheduler boost the process priority for a brief time (and
    then, reduce the priority in a nearly quadratic fashion until reaching
    it's original, or a lower, priority) to give it a better response time
    and increase the interactive feeling.

    However, for X11 based applications it seems a lot more difficult since
    all user-based input events are received by the X server itself (and not
    the process for which the event is intended). Based on the previous
    thoughts, the X11 server would be marked interactive, but not the
    application (like the word processor). This is not the desired effect.

    So the question is, how can we detect the ultimate process for which the
    user input event is intended? Should the X11 server help the scheduler
    by increasing the target process priority (it normally runs as root)?
    Should the window manager increase the priority of the process which
    owns the current foreground, active window? Solaris seems to work this
    way: when the user changes the focus to a new window, the window owner
    is brought into the interactive scheduling class. When the user chooses
    a new window, the window which loses the focus forces its owner to
    return to the time-shared scheduling class.

    What do you think about all of this? Should we use behavior-based
    against CPU-usage behavior to decide process interactivity?

    Thanks for listening.

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