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

    On Mon, 23 Apr 2007, Ingo Molnar wrote:
    > The "give scheduler money" transaction can be both an "implicit
    > transaction" (for example when writing to UNIX domain sockets or
    > blocking on a pipe, etc.), or it could be an "explicit transaction":
    > sched_yield_to(). This latter i've already implemented for CFS, but it's
    > much less useful than the really significant implicit ones, the ones
    > which will help X.

    Yes. It would be wonderful to get it working automatically, so please say
    something about the implementation..

    The "perfect" situation would be that when somebody goes to sleep, any
    extra points it had could be given to whoever it woke up last. Note that
    for something like X, it means that the points are 100% ephemeral: it gets
    points when a client sends it a request, but it would *lose* the points
    again when it sends the reply!

    So it would only accumulate "scheduling points" while multiuple clients
    are actively waiting for it, which actually sounds like exactly the right
    thing. However, I don't really see how to do it well, especially since the
    kernel cannot actually match up the client that gave some scheduling
    points to the reply that X sends back.

    There are subtle semantics with these kinds of things: especially if the
    scheduling points are only awarded when a process goes to sleep, if X is
    busy and continues to use the CPU (for another client), it wouldn't give
    any scheduling points back to clients and they really do accumulate with
    the server. Which again sounds like it would be exactly the right thing
    (both in the sense that the server that runs more gets more points, but
    also in the sense that we *only* give points at actual scheduling events).

    But how do you actually *give/track* points? A simple "last woken up by
    this process" thing that triggers when it goes to sleep? It might work,
    but on the other hand, especially with more complex things (and networking
    tends to be pretty complex) the actual wakeup may be done by a software
    irq. Do we just say "it ran within the context of X, so we assume X was
    the one that caused it?" It probably would work, but we've generally tried
    very hard to avoid accessing "current" from interrupt context, including

    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: 2007-04-23 22:09    [W:0.021 / U:8.108 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site