RE: FUSYN and RT
> > > > > /** A fuqueue, a prioritized wait queue usable from > kernel space. */ > > struct fuqueue { > > spinlock_t lock; > > struct plist wlist; > > struct fuqueue_ops *ops; > > }; > > > > Would the above spinlock_t be a raw_spinlock_t? This goes > back to my first question. I'm not sure how familiar you are > with Ingo's work, but he has turned all spinlocks into > mutexes, and when you really need an original spinlock, you > declare it with raw_spinlock_t. > This one probably should be a raw_spinlock. This lock is only held to protect access to the queues. Since the queues are already priority ordered, there is little benefit to ordering -the order of insertion- in case of contention on a queue, compared with the complexity. Just what you want to say to a guy who says he is tired ;) Sven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: FUSYN and RT
/** A fuqueue, a prioritized wait queue usable from kernel space. */ struct fuqueue { spinlock_t lock; struct plist wlist; struct fuqueue_ops *ops; }; Would the above spinlock_t be a raw_spinlock_t? This goes back to my first question. I'm not sure how familiar you are with Ingo's work, but he has turned all spinlocks into mutexes, and when you really need an original spinlock, you declare it with raw_spinlock_t. This one probably should be a raw_spinlock. This lock is only held to protect access to the queues. Since the queues are already priority ordered, there is little benefit to ordering -the order of insertion- in case of contention on a queue, compared with the complexity. Just what you want to say to a guy who says he is tired ;) Sven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Realtime preempt
Ingo, this patch turns off the preemptable BKL when either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected. Signed-off-by: Sven-Thorsten Dietrich <[EMAIL PROTECTED]> Index: linux-2.6.10-vaio/lib/Kconfig.RT === --- linux-2.6.10-vaio.orig/lib/Kconfig.RT 2005-02-18 11:13:42.050554215 + +++ linux-2.6.10-vaio/lib/Kconfig.RT2005-02-18 11:20:16.021273614 + @@ -144,5 +144,6 @@ config PREEMPT_BKL bool depends on PREEMPT_RT || !SPINLOCK_BKL + default n if !PREEMPT default y - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Realtime preempt
Ingo, this patch turns off the preemptable BKL when either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected. Signed-off-by: Sven-Thorsten Dietrich [EMAIL PROTECTED] Index: linux-2.6.10-vaio/lib/Kconfig.RT === --- linux-2.6.10-vaio.orig/lib/Kconfig.RT 2005-02-18 11:13:42.050554215 + +++ linux-2.6.10-vaio/lib/Kconfig.RT2005-02-18 11:20:16.021273614 + @@ -144,5 +144,6 @@ config PREEMPT_BKL bool depends on PREEMPT_RT || !SPINLOCK_BKL + default n if !PREEMPT default y - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Ingo wrote: > > * Sven Dietrich <[EMAIL PROTECTED]> wrote: > > > This patch adds a config option to allow you to select > whether timer > > IRQ runs in thread or not. > > this patch only changes xtime_lock back and forth - it does > in no way impact the 'threadedness' of the timer IRQ. (it > does not move the timer IRQ into an interrupt thread.) > > nor do we really want to make it configurable - it's > non-threaded right now and we'll see what effect this has on > the worst-case latencies. > > Ingo > Its clear that there are all sorts of issues with process accounting and other race conditions associated with running the timer in a thread. The timer IRQ does have a noticable impact especially on the slower CPUS. In this domain, precise process time accounting may not be all that important, as long as the scheduler does not get confused, and that lone NODELAY IRQ doesn't get delayed (as much). It would be nice if some of the process accounting could be pipelined or deferred, but I don't have those answers right now. Sven - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
No, this is not in arm. Here is the patch. Index: linux-2.6.10/include/asm-i386/spinlock.h === --- linux-2.6.10.orig/include/asm-i386/spinlock.h 2005-02-11 09:25:39.224240321 + +++ linux-2.6.10/include/asm-i386/spinlock.h 2005-02-11 09:25:58.006812173 + @@ -30,7 +30,7 @@ #define __raw_spin_is_locked(x)(*(volatile signed char *)(&(x)->lock) <= 0) #define __raw_spin_unlock_wait(x) \ - do { barrier(); } while(__spin_is_locked(x)) + do { barrier(); } while(__raw_spin_is_locked(x)) #define spin_lock_string \ "\n1:\t" \ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Molnar > Sent: Friday, February 11, 2005 12:34 AM > To: George Anzinger > Cc: William Weston; linux-kernel@vger.kernel.org > Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01 > > > > * George Anzinger wrote: > > > Possibly from: > > define __raw_spin_is_locked(x) (*(volatile signed char > *)(&(x)->lock) <= 0) > > #define __raw_spin_unlock_wait(x) \ > > do { barrier(); } while(__spin_is_locked(x)) > > in asm/spinlock.h > > > > should that be __raw_spin_is_locked(x) instead? > > yeah. Is this in the ARM patch? I havent applied the ARM > patch yet, waiting to see Thomas Gleixner's generic-hardirq > based one. (which is more compelling from an architectural > and long-term maintainance POV - but also more work to > address all of RMK's concerns.) > > Ingo > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to > [EMAIL PROTECTED] More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
No, this is not in arm. Here is the patch. Index: linux-2.6.10/include/asm-i386/spinlock.h === --- linux-2.6.10.orig/include/asm-i386/spinlock.h 2005-02-11 09:25:39.224240321 + +++ linux-2.6.10/include/asm-i386/spinlock.h 2005-02-11 09:25:58.006812173 + @@ -30,7 +30,7 @@ #define __raw_spin_is_locked(x)(*(volatile signed char *)((x)-lock) = 0) #define __raw_spin_unlock_wait(x) \ - do { barrier(); } while(__spin_is_locked(x)) + do { barrier(); } while(__raw_spin_is_locked(x)) #define spin_lock_string \ \n1:\t \ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ingo Molnar Sent: Friday, February 11, 2005 12:34 AM To: George Anzinger Cc: William Weston; linux-kernel@vger.kernel.org Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01 * George Anzinger george@mvista.com wrote: Possibly from: define __raw_spin_is_locked(x) (*(volatile signed char *)((x)-lock) = 0) #define __raw_spin_unlock_wait(x) \ do { barrier(); } while(__spin_is_locked(x)) in asm/spinlock.h should that be __raw_spin_is_locked(x) instead? yeah. Is this in the ARM patch? I havent applied the ARM patch yet, waiting to see Thomas Gleixner's generic-hardirq based one. (which is more compelling from an architectural and long-term maintainance POV - but also more work to address all of RMK's concerns.) Ingo - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Ingo wrote: * Sven Dietrich [EMAIL PROTECTED] wrote: This patch adds a config option to allow you to select whether timer IRQ runs in thread or not. this patch only changes xtime_lock back and forth - it does in no way impact the 'threadedness' of the timer IRQ. (it does not move the timer IRQ into an interrupt thread.) nor do we really want to make it configurable - it's non-threaded right now and we'll see what effect this has on the worst-case latencies. Ingo Its clear that there are all sorts of issues with process accounting and other race conditions associated with running the timer in a thread. The timer IRQ does have a noticable impact especially on the slower CPUS. In this domain, precise process time accounting may not be all that important, as long as the scheduler does not get confused, and that lone NODELAY IRQ doesn't get delayed (as much). It would be nice if some of the process accounting could be pipelined or deferred, but I don't have those answers right now. Sven - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Hi George, you may want to use this for reference. This patch adds a config option to allow you to select whether timer IRQ runs in thread or not. I'm not totally happy with the #ifdefs, but it may make witching back and forth easier. Sven > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > George Anzinger > Sent: Thursday, February 10, 2005 12:21 PM > To: Ingo Molnar > Cc: William Weston; linux-kernel@vger.kernel.org > Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01 > > > If I want to write a patch that will work with or without the > RT patch applied > is the following enough? > > #ifndef RAW_SPIN_LOCK_UNLOCKED > typedef raw_spinlock_t spinlock_t > #define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED > #endif > > > -- > George Anzinger george@mvista.com > High-res-timers: http://sourceforge.net/projects/high-res-timers/ > > - > To unsubscribe from this list: send the line "unsubscribe > linux-kernel" in the body of a message to > [EMAIL PROTECTED] More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > common_timer_irqthread.patch Description: Binary data
RE: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01
Hi George, you may want to use this for reference. This patch adds a config option to allow you to select whether timer IRQ runs in thread or not. I'm not totally happy with the #ifdefs, but it may make witching back and forth easier. Sven -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of George Anzinger Sent: Thursday, February 10, 2005 12:21 PM To: Ingo Molnar Cc: William Weston; linux-kernel@vger.kernel.org Subject: Re: [patch] Real-Time Preemption, -RT-2.6.11-rc3-V0.7.38-01 If I want to write a patch that will work with or without the RT patch applied is the following enough? #ifndef RAW_SPIN_LOCK_UNLOCKED typedef raw_spinlock_t spinlock_t #define RAW_SPIN_LOCK_UNLOCKED SPIN_LOCK_UNLOCKED #endif -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ common_timer_irqthread.patch Description: Binary data