[patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
downloaded from the usual place:

    http://redhat.com/~mingo/realtime-preempt/

i've implemented two new features:

 - new debugging feature: CONFIG_DEBUG_RT_LOCKING_MODE, which
   adds the /proc/sys/kernel/preempt_locks flag (default: 0). This way
   the 'locking model' can be switched runtime - very useful for
   debugging and profiling. Value 0 means that all spinlocks and rwlocks
   are implemented via raw spinlocks/rwlocks. (which disable preemption,
   increase latency, but improve throughput) Value 1 means the kernel 
   will fully preempt all locks again. (NOTE: the only safe runtime 
   switching of the locking model can be done while the system is idle, 
   so i've implemented the flag via two flags where the idle thread 
   propagates the new value from the user-flag to the kernel-flag. You 
   should put a "sleep 1" into scripts that switch the locking mode, to 
   guarantee that the new flag value is picked up.)

 - performance feature: i've implemented a new scheduler feature called 
   'delayed preemption', which turns sync wakeups into guaranteed 
   wakeups, while preserving their workload-batching properties. A 
   delayed preemption request is implemented via the 
   TIF_NEED_RESCHED_DELAYED flag, which runs in parallel to the 
   "immediate preemption" TIF_NEED_RESCHED flag. If this works out fine 
   then it will be a suitable replacement for the upstream sync-wakeups 
   facility as well.

delayed preemption already improved the performance of 'hackbench' under 
PREEMPT_RT quite signifiantly.

to build a -V0.7.47-20 tree, the following patches have to be applied:

   http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
   http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc6.bz2
   http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc6-V0.7.47-20

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Steven Rostedt]

On Tue, 2005-06-07 at 13:04 +0200, Ingo Molnar wrote:
> i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
> downloaded from the usual place:
> 

Ingo,

Here's the MAX_USER_RT_PRIO patch against your kernel.

-- Steve

--- kernel/sched.c.orig	2005-06-07 07:25:37.000000000 -0400
+++ kernel/sched.c	2005-06-07 07:27:38.000000000 -0400
@@ -2865,7 +2865,7 @@ static void trace_array(prio_array_t *ar
 			trace_special_pid(p->pid, p->prio,
 				p->policy == SCHED_NORMAL ?
 					p->static_prio :
-					MAX_USER_RT_PRIO - p->rt_priority);
+					(MAX_RT_PRIO-1) - p->rt_priority);
 		}
 	}
 }
@@ -3632,7 +3632,7 @@ int mutex_getprio(task_t *p)
 	int prio;
 
 	if (p->policy != SCHED_NORMAL)
-		prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
+		prio = MAX_RT_PRIO-1 - p->rt_priority;
 	else
 		prio = __effective_prio(p);
 	trace_special_pid(p->pid, p->prio, prio);
@@ -3794,7 +3794,7 @@ static void __setscheduler(struct task_s
 	p->policy = policy;
 	p->rt_priority = prio;
 	if (policy != SCHED_NORMAL)
-		p->prio = MAX_USER_RT_PRIO-1 - p->rt_priority;
+		p->prio = MAX_RT_PRIO-1 - p->rt_priority;
 	else
 		p->prio = p->static_prio;
 }
@@ -3826,7 +3826,8 @@ recheck:
 	 * 1..MAX_USER_RT_PRIO-1, valid priority for SCHED_NORMAL is 0.
 	 */
 	if (param->sched_priority < 0 ||
-	    param->sched_priority > MAX_USER_RT_PRIO-1)
+	    (p->mm && param->sched_priority > MAX_USER_RT_PRIO-1) ||
+	    (!p->mm && param->sched_priority > MAX_RT_PRIO-1))
 		return -EINVAL;
 	if ((policy == SCHED_NORMAL) != (param->sched_priority == 0))
 		return -EINVAL;

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

* Steven Rostedt <rostedt@goodmis.org> wrote:

> On Tue, 2005-06-07 at 13:04 +0200, Ingo Molnar wrote:
> > i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
> > downloaded from the usual place:
> > 
> 
> Ingo,
> 
> Here's the MAX_USER_RT_PRIO patch against your kernel.

thanks - i've added it to my tree and have uploaded the -47-23 patch. 

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Michal Schmidt]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Ingo Molnar wrote:
> i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
> downloaded from the usual place:

It doesn't build with CONFIG_RT_DEADLOCK_DETECT:
    CC      arch/i386/kernel/cpu/mtrr/main.o
arch/i386/kernel/cpu/mtrr/main.c:52: error: syntax error at '#' token
arch/i386/kernel/cpu/mtrr/main.c:52: error: `lockname' undeclared here 
(not in a function)
arch/i386/kernel/cpu/mtrr/main.c:52: error: initializer element is not
constant
arch/i386/kernel/cpu/mtrr/main.c:52: error: (near initialization for
`main_lock.lock.name')
arch/i386/kernel/cpu/mtrr/main.c:52: error: initializer element is not
constant
arch/i386/kernel/cpu/mtrr/main.c:52: error: (near initialization for
`main_lock.lock')
make[3]: *** [arch/i386/kernel/cpu/mtrr/main.o] Error 1


Patch attached.

Michal


[-- Attachment #2: rt-lockname.diff --]
[-- Type: text/plain, Size: 923 bytes --]

--- linux-RT.mich/include/linux/rt_lock.h.orig	2005-06-07 13:45:18.000000000 +0200
+++ linux-RT.mich/include/linux/rt_lock.h	2005-06-07 13:44:02.000000000 +0200
@@ -97,10 +97,10 @@ struct rt_mutex_waiter {
 };
 
 #ifdef CONFIG_RT_DEADLOCK_DETECT
-# define __RT_MUTEX_DEADLOCK_DETECT_INITIALIZER \
+# define __RT_MUTEX_DEADLOCK_DETECT_INITIALIZER(lockname) \
 	, .name = #lockname, .file = __FILE__, .line = __LINE__
 #else
-# define __RT_MUTEX_DEADLOCK_DETECT_INITIALIZER
+# define __RT_MUTEX_DEADLOCK_DETECT_INITIALIZER(lockname)
 #endif
 
 #ifdef CONFIG_DEBUG_RT_LOCKING_MODE
@@ -114,7 +114,7 @@ struct rt_mutex_waiter {
 #define __RT_MUTEX_INITIALIZER(lockname) \
 	{ .wait_lock = RAW_SPIN_LOCK_UNLOCKED, \
 	.wait_list = PLIST_INIT((lockname).wait_list, MAX_PRIO)  \
-	__RT_MUTEX_DEADLOCK_DETECT_INITIALIZER \
+	__RT_MUTEX_DEADLOCK_DETECT_INITIALIZER(lockname) \
 	__RT_MUTEX_DEBUG_RT_LOCKING_MODE_INITIALIZER }
 
 /*

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> Ingo Molnar wrote:
> >i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
> >downloaded from the usual place:
> 
> It doesn't build with CONFIG_RT_DEADLOCK_DETECT:
>    CC      arch/i386/kernel/cpu/mtrr/main.o
> arch/i386/kernel/cpu/mtrr/main.c:52: error: syntax error at '#' token
> arch/i386/kernel/cpu/mtrr/main.c:52: error: `lockname' undeclared here 

thanks, applied and i have released the -25 patch with this fix 
includes.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Esben Nielsen]

Hey,
 This is an old problem of cpu_freq.c not compiling. I (re)send a fix for
it. This time as a real patch...

Esben

--- drivers/cpufreq/cpufreq.c.orig      2005-06-07 15:47:25.000000000 +0200
+++ drivers/cpufreq/cpufreq.c   2005-06-07 16:31:01.000000000 +0200
@@ -605,7 +605,8 @@
        policy->cpu = cpu;
        policy->cpus = cpumask_of_cpu(cpu);
 
-       init_MUTEX_LOCKED(&policy->lock);
+       init_MUTEX(&policy->lock);
+       down(&policy->lock);
        init_completion(&policy->kobj_unregister);
        INIT_WORK(&policy->update, handle_update, (void *)(long)cpu);


On Tue, 7 Jun 2005, Ingo Molnar wrote:

> 
> i have released the -V0.7.47-20 Real-Time Preemption patch, which can be 
> downloaded from the usual place:
> 
>     http://redhat.com/~mingo/realtime-preempt/
> 
> i've implemented two new features:
> 
>  - new debugging feature: CONFIG_DEBUG_RT_LOCKING_MODE, which
>    adds the /proc/sys/kernel/preempt_locks flag (default: 0). This way
>    the 'locking model' can be switched runtime - very useful for
>    debugging and profiling. Value 0 means that all spinlocks and rwlocks
>    are implemented via raw spinlocks/rwlocks. (which disable preemption,
>    increase latency, but improve throughput) Value 1 means the kernel 
>    will fully preempt all locks again. (NOTE: the only safe runtime 
>    switching of the locking model can be done while the system is idle, 
>    so i've implemented the flag via two flags where the idle thread 
>    propagates the new value from the user-flag to the kernel-flag. You 
>    should put a "sleep 1" into scripts that switch the locking mode, to 
>    guarantee that the new flag value is picked up.)
> 
>  - performance feature: i've implemented a new scheduler feature called 
>    'delayed preemption', which turns sync wakeups into guaranteed 
>    wakeups, while preserving their workload-batching properties. A 
>    delayed preemption request is implemented via the 
>    TIF_NEED_RESCHED_DELAYED flag, which runs in parallel to the 
>    "immediate preemption" TIF_NEED_RESCHED flag. If this works out fine 
>    then it will be a suitable replacement for the upstream sync-wakeups 
>    facility as well.
> 
> delayed preemption already improved the performance of 'hackbench' under 
> PREEMPT_RT quite signifiantly.
> 
> to build a -V0.7.47-20 tree, the following patches have to be applied:
> 
>    http://kernel.org/pub/linux/kernel/v2.6/linux-2.6.11.tar.bz2
>    http://kernel.org/pub/linux/kernel/v2.6/testing/patch-2.6.12-rc6.bz2
>    http://redhat.com/~mingo/realtime-preempt/realtime-preempt-2.6.12-rc6-V0.7.47-20
> 
> 	Ingo
> -
> 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/
> 

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

* Esben Nielsen <simlo@phys.au.dk> wrote:

> Hey,
>  This is an old problem of cpu_freq.c not compiling. I (re)send a fix 
> for it. This time as a real patch...

thanks - i've applied it and have released the -47-27 patch with this 
fix included.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Michal Schmidt]

Ingo Molnar wrote:
> * Esben Nielsen <simlo@phys.au.dk> wrote:
> 
> 
>>Hey,
>> This is an old problem of cpu_freq.c not compiling. I (re)send a fix 
>>for it. This time as a real patch...
> 
> 
> thanks - i've applied it and have released the -47-27 patch with this 
> fix included.

Yes, that's an obviously safe fix.
I asked on the cpufreq mailing list about this lock. Here's the answer I 
got from Dominik Brodowski:

Dominik Brodowski wrote:
> On Wed, Jun 01, 2005 at 06:57:12PM +0200, Michal Schmidt wrote:
> 
>> Hello,
>> I think that it's not necessary to take the policy->lock in cpufreq_add_dev.
>> Am I missing something? What is the lock supposed to protect from?
> 
> 
> Well, indeed it is not necessary to take the policy->lock, although it
> doesn't do any harm AFAICS. I added it to make sure that _all_ accesses to
> the data is protected by the lock, how serialized they may ever be..
> 
> Thanks,
> 	Dominik


Michal

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Peter Zijlstra]

On Tue, 2005-06-07 at 18:04 +0200, Ingo Molnar wrote:

> thanks - i've applied it and have released the -47-27 patch with this 
> fix included.

In how bad a shape is ALL_TASKS_PI in that patch?
And is your TASK_NONINTERACTIVE patch needed with -RT kernels?; it
doesn't apply cleanly but I guess I can manage to get it in; it's only a
few lines of code anyway ;-)


-- 
Peter Zijlstra <a.p.zijlstra@chello.nl>

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

* Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:

> On Tue, 2005-06-07 at 18:04 +0200, Ingo Molnar wrote:
> 
> > thanks - i've applied it and have released the -47-27 patch with this 
> > fix included.
> 
> In how bad a shape is ALL_TASKS_PI in that patch?

it hasnt been used with the plist code at all.

> And is your TASK_NONINTERACTIVE patch needed with -RT kernels?; it 
> doesn't apply cleanly but I guess I can manage to get it in; it's only 
> a few lines of code anyway ;-)

the delayed-preemption feature in the -RT kernel has a similar effect, 
so it should not be needed.

	Ingo

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Michal Schmidt]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

Ingo Molnar wrote:
>  - performance feature: i've implemented a new scheduler feature called 
>    'delayed preemption', [...]

So far it's only for i386. On x84_64 the kernel doesn't compile.
Attached is my attempt to make it work on x86_64.
The diff is against RT-V0.7.47-26.

Warning: I don't know what I'm doing! But at least it compiles and boots 
for me.

Michich

[-- Attachment #2: rt-x86_64-delayed-preemption.diff --]
[-- Type: text/plain, Size: 3013 bytes --]

diff -Nurp -X linux-RT.mich/Documentation/dontdiff linux-RT/arch/x86_64/kernel/entry.S linux-RT.mich/arch/x86_64/kernel/entry.S
--- linux-RT/arch/x86_64/kernel/entry.S	2005-06-07 19:07:30.000000000 +0200
+++ linux-RT.mich/arch/x86_64/kernel/entry.S	2005-06-07 20:48:26.000000000 +0200
@@ -211,8 +211,8 @@ sysret_check:		
 	/* Handle reschedules */
 	/* edx:	work, edi: workmask */	
 sysret_careful:
-	bt $TIF_NEED_RESCHED,%edx
-	jnc sysret_signal
+	testl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edx
+	jz sysret_signal
 	sti
 	pushq %rdi
 	call schedule
@@ -231,7 +231,7 @@ sysret_signal:
 	leaq -ARGOFFSET(%rsp),%rdi # &pt_regs -> arg1
 	xorl %esi,%esi # oldset -> arg2
 	call ptregscall_common
-1:	movl $_TIF_NEED_RESCHED,%edi
+1:	movl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edi
 	jmp sysret_check
 	
 	/* Do syscall tracing */
@@ -280,8 +280,8 @@ int_with_check:
 	/* First do a reschedule test. */
 	/* edx:	work, edi: workmask */
 int_careful:
-	bt $TIF_NEED_RESCHED,%edx
-	jnc  int_very_careful
+	testl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edx
+	jz int_very_careful
 	sti
 	pushq %rdi
 	call schedule
@@ -310,7 +310,7 @@ int_signal:
 	movq %rsp,%rdi		# &ptregs -> arg1
 	xorl %esi,%esi		# oldset -> arg2
 	call do_notify_resume
-1:	movl $_TIF_NEED_RESCHED,%edi	
+1:	movl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edi	
 int_restore_rest:
 	RESTORE_REST
 	cli
@@ -478,8 +478,8 @@ bad_iret:
 	
 	/* edi: workmask, edx: work */	
 retint_careful:
-	bt    $TIF_NEED_RESCHED,%edx
-	jnc   retint_signal
+	testl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edx
+	jz    retint_signal
 	sti
 	pushq %rdi
 	call  schedule
@@ -499,7 +499,7 @@ retint_signal:
 	call do_notify_resume
 	RESTORE_REST
 	cli
-	movl $_TIF_NEED_RESCHED,%edi
+	movl $(_TIF_NEED_RESCHED|_TIF_NEED_RESCHED_DELAYED),%edi
 	GET_THREAD_INFO(%rcx)
 	jmp retint_check
 
diff -Nurp -X linux-RT.mich/Documentation/dontdiff linux-RT/include/asm-x86_64/thread_info.h linux-RT.mich/include/asm-x86_64/thread_info.h
--- linux-RT/include/asm-x86_64/thread_info.h	2005-06-07 14:05:32.000000000 +0200
+++ linux-RT.mich/include/asm-x86_64/thread_info.h	2005-06-07 19:12:01.000000000 +0200
@@ -103,6 +103,7 @@ static inline struct thread_info *stack_
 #define TIF_IRET		5	/* force IRET */
 #define TIF_SYSCALL_AUDIT	7	/* syscall auditing active */
 #define TIF_SECCOMP		8	/* secure computing */
+#define TIF_NEED_RESCHED_DELAYED	9	/* rescheduling necessary upon return to userspace */
 #define TIF_POLLING_NRFLAG	16	/* true if poll_idle() is polling TIF_NEED_RESCHED */
 #define TIF_IA32		17	/* 32bit process */ 
 #define TIF_FORK		18	/* ret_from_fork */
@@ -117,6 +118,7 @@ static inline struct thread_info *stack_
 #define _TIF_IRET		(1<<TIF_IRET)
 #define _TIF_SYSCALL_AUDIT	(1<<TIF_SYSCALL_AUDIT)
 #define _TIF_SECCOMP		(1<<TIF_SECCOMP)
+#define _TIF_NEED_RESCHED_DELAYED	(1<<TIF_NEED_RESCHED_DELAYED)
 #define _TIF_POLLING_NRFLAG	(1<<TIF_POLLING_NRFLAG)
 #define _TIF_IA32		(1<<TIF_IA32)
 #define _TIF_FORK		(1<<TIF_FORK)

Re: [patch] Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

[Ingo Molnar]

* Michal Schmidt <xschmi00@stud.feec.vutbr.cz> wrote:

> Ingo Molnar wrote:
> > - performance feature: i've implemented a new scheduler feature called 
> >   'delayed preemption', [...]
> 
> So far it's only for i386. On x84_64 the kernel doesn't compile.
> Attached is my attempt to make it work on x86_64.
> The diff is against RT-V0.7.47-26.
> 
> Warning: I don't know what I'm doing! But at least it compiles and boots 
> for me.

i'd not have done it differently :) The most important bits are the 
entry.S changes: to correctly update bit-tests to mask-tests and to 
extend any byte-test to a word-test (because bit 9 falls outside of the 
low byte) - you've done that all correctly. I've applied your patch and 
have uploaded the -47-28 release. Boots fine on my x64 box too.

	Ingo