Skip to contentSkip to conversation

Enforce nkaffinity unconditionally

RFC PATCH Applied Jan Kiszka 3 participants 4 messages Oct 16, 2007 – Oct 17, 2007

lore
Share & tools
lore

Jan Kiszka

author
#0 lore raw

RFC PATCH 1/1 Enforce nkaffinity unconditionally

Hi,

after looking at the reason for the nkaffinity-vs.-POSIX issue [1] again, I came to the conclusion that there is no way to apply the current global affinity scheme on the POSIX skin. This scheme goes like this:
- If the user provides whatever thread affinity _explicitly_, use this one.
- If the user doesn't do so, apply the global nkaffinity.

In kernel space, is is simple to differentiate between both cases, because all affinity fiddling for all skins go through Xenomai's hands. But for the user space POSIX skin, we rely on the task affinity that is
set using standard Linux services, and that one has no "dirty-bit" to
tell both scenarios apart.

So my conclusion is that we should rather apply the nkaffinity always, ie. logically AND it with the desired (or default) affinity. The system's default behaviour will still be the same compared to earlier Xenomai versions, as nkaffinity is ALL_CPUS by default. I also think this behaviour is easier to understand for the user than the current approach.

Any concerns about the (yet untested) attached patch?

Jan

[1] https://mail.gna.org/public/xenomai-core/2007-10/msg00012.html

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
ksrc/nucleus/pod.c +1 -2
Index: xenomai/ksrc/nucleus/pod.c
===================================================================
@@ -801,8 +801,7 @@ int xnpod_start_thread(xnthread_t *threa
 	if (!xnthread_test_state(thread, XNDORMANT))
 		return -EBUSY;
 
-	if (xnarch_cpus_equal(affinity, XNPOD_ALL_CPUS))
-		affinity = nkaffinity;
+	xnarch_cpus_and(affinity, affinity, nkaffinity);
 
 	xnlock_get_irqsave(&nklock, s);
ksrc/nucleus/shadow.c +4 -8
Index: xenomai/ksrc/nucleus/shadow.c
===================================================================
@@ -1297,7 +1297,7 @@ int xnshadow_map(xnthread_t *thread, xnc
 {
 	xnarch_cpumask_t affinity;
 	unsigned muxid, magic;
-	int prio, err, cpu;
+	int prio, err;
 
 	if (!xnthread_test_state(thread, XNSHADOW))
 		return -EINVAL;

@@ -1347,13 +1347,9 @@ int xnshadow_map(xnthread_t *thread, xnc
 	xnthread_set_state(thread, XNMAPPED);
 	xnpod_suspend_thread(thread, XNRELAX, XN_INFINITE, XN_RELATIVE, NULL);
 
-	/* Restrict affinity to a single CPU of nkaffinity or
-	   the current set. */
-	if (xnarch_cpus_equal(current->cpus_allowed, XNPOD_ALL_CPUS))
-		cpu = xnarch_first_cpu(nkaffinity);
-	else
-		cpu = xnarch_first_cpu(current->cpus_allowed);
-	affinity = xnarch_cpumask_of_cpu(cpu);
+	/* Restrict affinity to a single CPU of nkaffinity & current set. */
+	xnarch_cpus_and(affinity, current->cpus_allowed, nkaffinity);
+	affinity = xnarch_cpumask_of_cpu(xnarch_first_cpu(affinity));
 	set_cpus_allowed(current, affinity);
 
 	if (u_completion) {
#1 lore raw
Quoted 16 lines · Jan Kiszka

Hi,

after looking at the reason for the nkaffinity-vs.-POSIX issue [1] again, I came to the conclusion that there is no way to apply the current global affinity scheme on the POSIX skin. This scheme goes like this:
- If the user provides whatever thread affinity _explicitly_, use this one.
- If the user doesn't do so, apply the global nkaffinity.

In kernel space, is is simple to differentiate between both cases, because all affinity fiddling for all skins go through Xenomai's hands. But for the user space POSIX skin, we rely on the task affinity that is
set using standard Linux services, and that one has no "dirty-bit" to
tell both scenarios apart.

Quoted 8 lines

So my conclusion is that we should rather apply the nkaffinity always, ie. logically AND it with the desired (or default) affinity. The system's default behaviour will still be the same compared to earlier Xenomai versions, as nkaffinity is ALL_CPUS by default. I also think this behaviour is easier to understand for the user than the current approach.

Any concerns about the (yet untested) attached patch?

Well... Thanks for working in my stead. I had a look a the posix situation but could not find the place in the code where the affinity was set for user-space posix threads.

But when looking at the way nkaffinity worked, I wondered why it was not set globally with a cpus_and on the tasks affinity. So, I basically agree with your patch (if it does what I think it does).

Signature · 1 line
                                               Gilles Chanteperdrix
author
#2 lore raw
Quoted 26 lines · Gilles Chanteperdrix
Quoted 16 lines · Jan Kiszka

Hi,

after looking at the reason for the nkaffinity-vs.-POSIX issue [1] again, I came to the conclusion that there is no way to apply the current global affinity scheme on the POSIX skin. This scheme goes like this:
- If the user provides whatever thread affinity _explicitly_, use this one.
- If the user doesn't do so, apply the global nkaffinity.

In kernel space, is is simple to differentiate between both cases, because all affinity fiddling for all skins go through Xenomai's hands. But for the user space POSIX skin, we rely on the task affinity that is
set using standard Linux services, and that one has no "dirty-bit" to
tell both scenarios apart.

Quoted 8 lines

So my conclusion is that we should rather apply the nkaffinity always, ie. logically AND it with the desired (or default) affinity. The system's default behaviour will still be the same compared to earlier Xenomai versions, as nkaffinity is ALL_CPUS by default. I also think this behaviour is easier to understand for the user than the current approach.

Any concerns about the (yet untested) attached patch?

Quoted 7 lines

Well... Thanks for working in my stead. I had a look a the posix situation but could not find the place in the code where the affinity was set for user-space posix threads.

But when looking at the way nkaffinity worked, I wondered why it was not set globally with a cpus_and on the tasks affinity. So, I basically agree with your patch (if it does what I think it does).

Tested, and I can confirm it works as it should do. Philippe, please apply.

Jan

Signature · 2 lines
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux
Applied
#3 lore raw
Quoted 10 lines · Jan Kiszka
Quoted 8 lines · Gilles Chanteperdrix
Quoted 4 lines · Jan Kiszka

Hi,

aft
Any concerns about the (yet untested) attached patch?

Well... Thanks for working in my stead. I had a look a the posix situation but could not find the place in the code where the

affinity

Quoted 8 lines
Quoted 5 lines

was set for user-space posix threads.

But when looking at the way nkaffinity worked, I wondered why it was not set globally with a cpus_and on the tasks affinity. So, I basically agree with your patch (if it does what I think it does).

Tested, and I can confirm it works as it should do. Philippe, please apply.

Merged, thanks.

Signature · 1 line
Philippe.