Skip to contentSkip to conversation

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

PATCH In review Ingo Molnar 5 participants 12 messages Jun 7, 2005

lore
Share & tools
lore

Ingo Molnar

author
#0 lore raw

PATCH 1/1 Real-Time Preemption, -RT-2.6.12-rc6-V0.7.47-20

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

#1 lore raw
Quoted 3 lines · Ingo Molnar

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

sched.c renamed from sched.c.orig +5 -4
@@ -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;
author
#2 lore raw
Quoted 8 lines · Steven Rostedt
Quoted 3 lines · Ingo Molnar

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

#3 lore raw
In reply to Ingo Molnar
Quoted 1 line · Ingo Molnar

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

include/linux/rt_lock.h renamed from include/linux/rt_lock.h.orig +3 -3
@@ -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 }
 
 /*
author Applied
#4 lore raw
Quoted 8 lines · Michal Schmidt
Quoted 2 lines · Ingo Molnar

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

#5 lore raw
In reply to Ingo Molnar

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

cpufreq/cpufreq.c 2005-06-07 16:31:01.000000000 +0200 renamed from cpufreq/cpufreq.c.orig 2005-06-07 15:47:25.000000000 +0200 +2 -1
@@ -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);
Quoted 46 lines · 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

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

author
#6 lore raw
Quoted 3 lines · 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...

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

Ingo

#7 lore raw
Quoted 8 lines · Ingo Molnar
Quoted 2 lines · 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...

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:

Quoted 7 lines · Dominik Brodowski
Quoted 3 lines · Michal Schmidt

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?

Quoted 6 lines

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

#8 lore raw
In reply to Ingo Molnar
Quoted 2 lines · Ingo Molnar

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 ;-)

Signature · 1 line
Peter Zijlstra <[email protected]>
author
#9 lore raw
Quoted 6 lines · Peter Zijlstra
Quoted 2 lines · Ingo Molnar

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.

Quoted 3 lines

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

#10 lore raw
In reply to Ingo Molnar
Quoted 2 lines · Ingo Molnar

- 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

arch/x86_64/kernel/entry.S +9 -9
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
@@ -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
include/asm-x86_64/thread_info.h +2 -0
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
@@ -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)
author
#11 lore raw
Quoted 10 lines · Michal Schmidt
Quoted 2 lines · Ingo Molnar

- 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