RE: FUSYN and RT

2005-04-15 Thread Sven Dietrich
> > > 
> > /** 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

2005-04-15 Thread Sven Dietrich
   
  /** 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

2005-02-18 Thread Sven Dietrich

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

2005-02-18 Thread Sven Dietrich

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

2005-02-11 Thread Sven Dietrich


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

2005-02-11 Thread Sven Dietrich

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

2005-02-11 Thread Sven Dietrich

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

2005-02-11 Thread Sven Dietrich


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

2005-02-10 Thread Sven Dietrich

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

2005-02-10 Thread Sven Dietrich

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