lkml.org 
[lkml]   [1998]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Schedule idle
    On Mon, Nov 09, 1998 at 08:33:28PM +0100, Rik van Riel wrote:
    > > Linux kernel assumes that a kernel mode thread should progess
    > > until _it_ (the thread) decides to reschedule
    > >
    > > Priority based RT assumes that the highest priority runnable
    > > process will advance at any time.
    > >
    > > If the OS tries to believe both propositions at the same time it will die.
    >
    > Not neccesarily. There are certain things you can do
    > do avoid this situation. Firstly, RT processes usually
    > don't take up loads of CPU time. If they do, you're
    > better off with a separate system anyway; you're
    > right on that.

    Orthogonal. It's not how much time they use, it's what gets to run when.


    > OTOH, I have been running RT processes for a long
    > time now (can you say 1.3) without actually
    > experiencing any of the problems you mentioned.

    That's because of the modest implementation of Posix soft RT.

    >
    > > >way, the problem is not with the SCHED_IDLE patch.
    > >
    > > Of course it is.
    >
    > The SCHED_IDLE idea is just an extension of the
    > realtime paradigm. I take it you're not really
    > serious about wanting to back _that_ out of the
    > kernel.

    "just an extension" is not a meaningful term. Posix soft rt is a
    peculiar spec -- all api and almost no semantics. So supporting it is
    not a problem -- pretending that it can be meaningfully extended is a problem.

    > Hint: you don't need the SCHED_IDLE patch to bump
    > into the priority inversion scheme, hence the
    > problem is somewhere else.

    It's good to try to define terms precisely. If we define "priority inversion"
    as the condition of a higher priority task waiting for a lower priority task,
    then we see that this is an inescapable property of the Linux design.
    For example, (nice -10 cat junk | nice 10 cat ) makes the higher priority
    "cat" wait on the lower priority "cat" once the pipe fills. Or consider
    the do_fork code and ask what happens if high priority process A wants
    to fork after low priority process B has acquired the semaphore and kernel
    lock. So "priority inversion" is not a "problem" in Linux, it is an
    intrinsic part of the operation of the kernel. It only becomes a problem
    when people want to pretend that this design can also support RT semantics.
    One might just as well claim that there is a lack of mobility problem in
    a furnace -- furnaces are supposed to produce heat, not to move, and
    UNIXs are designed to optimize throughput, not support a rather simple
    minded RT semantics.

    It's worth noting that even in pure priority scheduled systems, priority
    inversion is a fact of life as soon as there is any kind of communication or
    resource sharing. You can only fix this problem in papers where you
    declare all tasks to be assumed to be noninterfering.



    >
    > > >Consider the following scenario:
    > > >- SCHED_OTHER process bangs on the FS
    >
    > Which is fully threaded, except for some properly
    > protected areas.
    >
    > > >- low-priority RT process computes primes or whatever
    > > >- high-priority RT process occasionally wakes up, reads a device and
    > > > uses the FS.
    >
    > Priority inheritance would solve the problem.

    Explain how.
    And consider: Low priority A allocates a buffer and sleeps waiting for I/O
    "RT" process B asks for a buffer and finds none.
    or
    Low priority process A enters a system call and does
    global_cli

    High priority task B calls global_cli



    >
    > > >Just as in your example, the important RT process gets locked out of
    > > >the FS if schedule() is called with locks held. So, the problem isn't
    > > >with SCHED_IDLE, it's elsewhere.
    > >
    > > The problem is that you are introducing a complex mechanism to do
    > > something unspecified.
    >
    > The 'something unspecified' means solving possible
    > problems with priority inversion that might be
    > hidden somewhere in the code.

    Still no specification. What is the desired semantics of process operation?
    If a RT process X is runnable and the highest priority, when should it
    run? Soon? At once? As soon as a pre-emption point is reached?


    >
    > > Spell out what "important RT" means precisely and you will be in a
    > > position to make your code work. If you want a completely
    > > preemptable kernel, you have your work cut out for you. God alone
    > > knows what it means for a high priority RT task to "use the FS".
    >
    > Uhmm, this is rather vague -- what is the hidden message
    > in this paragraph?
    >


    There's no hidden message. I'm simply pointing out that if you have
    specifications that depend on undefined words e.g. "important" and "RT"
    whcih have absolutely no meaning in this context, then your solutions will
    be, in the words of some guy, like a hippo blundering around.


    --

    ---------------------------------
    Victor Yodaiken
    Department of Computer Science
    New Mexico Institute of Mining and Technology
    Socorro NM 87801
    Homepage http://www.cs.nmt.edu/~yodaiken
    PowerPC Linux page http://linuxppc.cs.nmt.edu
    Real-Time Page http://rtlinux.org


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

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.046 / U:32.284 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site