Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1

From: hui (bhuey_at_lnxw.com)
Date: 10/14/04

  • Next message: Ingo Molnar: "Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1" 
    Date:	Thu, 14 Oct 2004 12:46:47 -0700
To: Mark_H_Johnson@raytheon.com

    On Thu, Oct 14, 2004 at 02:13:15PM -0500, Mark_H_Johnson@raytheon.com wrote:
    ...
    > be some real time value so that nice -20 jobs won't bother them either.
    > A possibility that comes to mind is to schedule IRQ's at a range higher
    > than
    > available to all real time application tasks. I'll mention another
    > possibility below as well.

    The interrupt priority range probably needs to be increased to accommodate the
    increased design demand of RT applications.

    > In the systems I have to deal with, I do not have a clear criteria
    > to set priorities of interrupts relative to each other. For example, I
    > have a real time simulation system using the following devices:
    > - occasional disk access to simulate disk I/O
    > - real time network traffic
    > - real time delivery of interrupts from a PCI timer card and APIC timers
    > - real time interrupts from a shared memory interface
    > The priorities of real time tasks are basically assigned based on the
    > rate of execution. 80 Hz tasks run at a higher priority than 60 Hz, 60 Hz >
    > 40 Hz, and so on. A number of tasks can access each device.

    Crank it higher 120hz and see what kind of jitter your getting. Hit
    something with high memory load, large, mmap images, swap and friends.

    > It would be "better" if the priority of the hardware interrupts somehow
    > inherited the priority (absolute or relative to other IRQ's) of the task
    > making the request. So in that way, a 40 Hz task making a network transfer
    > would somehow boost the priority of the network interface until that
    > transfer was complete. It would also be good if the queue of pending
    > transfers was reordered by RT priority, but I don't see that as an easy
    > thing to implement currently in Linux (but I can ask... :-) ).

    That's an RT app slippery slope and it should be handled by some kind of
    in-kernel or kernel locking aware facilties. The reason why Linux is
    ideal for RTOS usage is directly related to all of the SMP work that's
    been done over the years. Contention, therefore the need for priority
    inheritance, is evil. If you need that kind of functionality, then you
    might be good to consider the scheduling indeterminancy of the lock chain
    being aquired and it should have little or no overlap with things like
    irq-threads. The system should be decoupled (queues, etc...) if possible
    and you shouldn't abuse priority inheritance. The use of priority
    inheritance should be considered a kind lock contention overload and
    the algorithms it bounds should be optimized. In your case, the network
    stack might need to be broken up to provide the kind of granularity
    and control need to attach on a socket per process/thread basis, just
    like Jeffery Hsu's lockless network stack effort in DragonFly BSD.

    Long priority inheritance chains is an app-level indeterminacy nightmare
    and either indicates an improperly written application or nasty SMP
    contention issue. That's how I see it.

    > Needless to say, if you implemented priority inheritance, when the 40 Hz
    > task is not doing network transfers, I would just as soon prefer that
    > other network operations (say from a 2 Hz tasks) does not get a priority
    > boost above a 20 Hz task accessing another device.

    bill
    -
    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/

  • Next message: Ingo Molnar: "Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1"

    Relevant Pages

    • Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
      ... Perhaps I am old fashioned, but in building a real time system, I consider ... priority than real time tasks. ... to set priorities of interrupts relative to each other. ... a 40 Hz task making a network transfer ...
      (Linux-Kernel)
    • Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1
      ... > Perhaps I am old fashioned, but in building a real time system, I ... > consider hardware interrupt processing as something that is always at ... to the IRQ handling thread. ... determines the policy and the priority of interrupt handling. ...
      (Linux-Kernel)
    • Re: Why yield in coredump_wait? [was: Re: Resent: BUG in RT 45-01 when RT program dumps core]
      ... >> Would it not make more sense to kick a task out of hard real time at the ... >> point it begins dumping core. ... > rid of that yield. ... code should break if executing with RT priority. ...
      (Linux-Kernel)
    • Re: Posix real time signal handling on timeout.
      ... > If user creates a timerwith posix real time API: ... >timer_create with the highest priority real time signal ... Both signals will be made pending "simultaneously", ... >handlers have the highest priority irrespective of any user task(real ...
      (comp.os.linux.embedded)
    • Re: Cheap wireless (RF) receiver/transmitter solution?
      ... >> would like to translate the results real time to some comodity pc ... >A network of computers and a simple program is a lot easier, ... if the students have no laptops. ... We are trying to minimize non-important radio ...
      (sci.electronics.misc)
    Loading