lkml.org 
[lkml]   [2005]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
    Date
    On Thu, 03 Feb 2005 21:47:11 +0100, Ingo Molnar wrote:

    >
    > * Con Kolivas <kernel@kolivas.org> wrote:
    >
    >> > * real inter-process handoff. i am thinking of something like
    >> > sched_yield(), but it would take a TID as the target
    >> > of the yield. this would avoid all the crap we have to
    >> > go through to drive the graph of clients with FIFO's and
    >> > write(2) and poll(2). Futexes might be a usable
    >> > approximation in 2.6 (we are supporting 2.4, so we can't
    >> > use them all the time)
    >>
    >> yield_to(tid) should not be too hard to implement. Ingo? What do you
    >> think?
    >
    > i dont really like it - it's really the wrong interface to use.

    Would it be nice to create scheduling domains, so the processes in a
    domain have priority relative to each other. The second highest priority
    FIFO task could actually be a scheduling sub-domain (which appears to be a
    child process of task A). In that scheduling sub-domain would be all the
    real-time tasks that A manages the scheduling of. It gets to set their
    relative priorities and sched class.

    Task A could then make the first FIFO client be at the top of that domain,
    with the second task to run being at the next priority, etc. Then Task A
    blocks waiting for a watchdog timer so it can keep an eye on things. This
    way yield_to would actually be almost a special case of a pre-configurable
    sequence of operations which can have FIFO parts, RR parts, and OTHER
    parts. Task A could also put one of its own threads in the sub-domain to
    be able to change its state at a certain point in the sequence rather than
    a certain time.

    This could be extended to allow init to own a sub-domain for each user
    that it could manage to allow users to each have real-time operations, and
    daemons with high priorities relative to that user's other tasks, but
    without interfering with other users (or giving root an automatic
    advantage). It could make accounting easier, and allow users to get total
    priority equal to the amount of money they pay.

    I know this could be a lot of work, but is it sound in principle?

    How would you do better than RR between users with domains at the same
    priority though... That I'm not sure of. IE, it might be good to switch
    back to any domain that has a recently woken task more frequently but for
    less time then extend the time and decrease the frequency as the time
    since waking increases. That way users tasks could respond quickly to
    events without ever being able to cause or suffer from starvation.

    Unfortunately, O(1) behaviour would be a must, and that scheme could be
    particularly hard to implement in O(1) :)

    Is it useful, too much work, over-engineered, logically impossible?

    --
    Tristan Wibberley

    -
    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: 2005-03-22 14:10    [W:2.296 / U:0.700 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site