lkml.org 
[lkml]   [2007]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [REPORT] cfs-v4 vs sd-0.44


    On Mon, 23 Apr 2007, Nick Piggin wrote:
    > > If you have a single client, the X server is *not* more important than the
    > > client, and indeed, renicing the X server causes bad patterns: just
    > > because the client sends a request does not mean that the X server should
    > > immediately be given the CPU as being "more important".
    >
    > If the client is doing some processing, and the user moves the mouse, it
    > feels much more interactive if the pointer moves rather than waits for
    > the client to finish processing.

    .. yes. However, that should be automatically true if the X process just
    has "enough CPU time" to merit being scheduled to.

    Which it normally should always have, exactly because it's an
    "interactive" process (regardless of how the scheduler is done - any
    scheduler should always give sleepers good latency. The current one
    obviously does it by giving interactivity-bonuses, CFS does it by trying
    to be fair in giving out CPU time).

    The problem tends to be the following scenario:

    - the X server is very CPU-busy, because it has lots of clients
    connecting to it, and it's not getting any "bonus" for doing work for
    those clients (ie it uses up its time-slice and thus becomes "less
    important" than other processes, since it's already gotten its "fair"
    slice of CPU - never mind that it was really unfair to not give it
    more)

    - there is some process that is *not* dependent on X, that can (and does)
    run, because X has spent its CPU time serving others.

    but the point I'm trying to make is that X shouldn't get more CPU-time
    because it's "more important" (it's not: and as noted earlier, thinking
    that it's more important skews the problem and makes for too *much*
    scheduling). X should get more CPU time simply because it should get it's
    "fair CPU share" relative to the *sum* of the clients, not relative to any
    client individually.

    Once you actually do give the X server "fair share" of the CPU, I'm sure
    that you can still get into bad situations (trivial example: make clients
    that on purpose do X requests that are expensive for the server, but are
    cheap to generate). But it's likely not going to be an issue in practice
    any more.

    Scheduling is not something you can do "perfectly". There's no point in
    even trying. To do "perfect" scheduling, you'd have to have ESP and know
    exactly what the user expects and know the future too. What you should aim
    for is the "obvious cases".

    And I don't think anybody really disputes the fact that a process that
    does work for other processes "obviously" should get the CPU time skewed
    towards it (and away from the clients - not from non-clients!). I think
    the only real issue is that nobody really knows how to do it well (or at
    all).

    I think the "schedule by user" would be reasonable in practice - not
    perfect by any means, but it *does* fall into the same class of issues:
    users are not in general "more important" than other users, but they
    should be treated fairly across the user, not on a per-process basis.

    Linus
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-04-23 18:01    [W:0.023 / U:32.292 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site