Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1

Mark_H_Johnson_at_raytheon.com
Date: 11/04/04

  • Next message: Roland Dreier: "Re: patch for sysfs in the cyclades driver"
    To: Ingo Molnar <mingo@elte.hu>
    Date:	Thu, 4 Nov 2004 10:53:58 -0600
    
    

    >> I can set those as well but then I'd probably have to follow with
    >> the X server and everything else in the chain. The starvation problem
    >> ripples across the system.
    >
    >X should be scheduled on the other CPU just fine. Only per-CPU kernel
    >threads (which are affine to their particular CPU) are affected by this
    >problem - ordinary tasks not. I.e. the system threads that have /0 and
    >/1 in their name. In theory you should not even need to chrt the hardirq
    >threads, those should schedule fine too.
    Perhaps "should be fine" but the test I just ran indicates otherwise.
    The kernel is -V0.7.7 plus the patch you just sent me.
    All IRQ and /# tasks were set to RT priority 99.

    Started the X test and the display locked up almost immediately while
    ping responses continued to flow on a regular basis. After several seconds
    I could see the display update / move the mouse & then the display locked
    up again. It went back and forth a couple cycles and did not get unstuck
    until the RT audio application quit (over 250000 samples).

    I will let it run to see if I can reproduce the deadlock or if the symptoms
    change with one of the other tests.

    --Mark H Johnson
      <mailto:Mark_H_Johnson@raytheon.com>

    -
    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: Roland Dreier: "Re: patch for sysfs in the cyclades driver"

    Relevant Pages

    • Re: [patch] Real-Time Preemption, -RT-2.6.10-rc1-mm2-V0.7.1
      ... X should be scheduled on the other CPU just fine. ... I.e. the system threads that have /0 and ... those should schedule fine too. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: question about contest benchmark
      ... > preferentially to a pure CPU bound process like a build. ... So you want it to schedule that big image that's already used 5 ... minutes of CPU since it started in preference to ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] [1/2] random: SMP locking
      ... >> occur, perform IO, schedule away and the same CPU tries to take the same ... >> lock via a different process. ... 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/ ...
      (Linux-Kernel)
    • Re: dynamic-hz
      ... >> probably should just call schedule() directly. ... > gives up cpu until waitqueue wakeup or signal is received, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: 2.7 thoughts
      ... >> holding a spinlock) and dump registers out to memory. ... >> takes to schedule out whatever's currently running on the thing. ... it is safe to remove the CPU. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)

    Loading