[PATCH] sched hardcode non-smp set_cpus_allowed

[PATCH] sched hardcode non-smp set_cpus_allowed

[Paul Jackson]

Simplify the UP (1 CPU) implementatin of set_cpus_allowed.

The one CPU is hardcoded to be cpu 0 - so just test for
that bit, and avoid having to pick up the cpu_online_map.

Signed-off-by: Paul Jackson <pj@sgi.com>

---

 include/linux/sched.h |    2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- 2.6.14-rc5-mm1.orig/include/linux/sched.h	2005-10-27 00:26:36.000000000 -0700
+++ 2.6.14-rc5-mm1/include/linux/sched.h	2005-10-27 00:35:34.000000000 -0700
@@ -945,7 +945,7 @@ extern int set_cpus_allowed(task_t *p, c
 #else
 static inline int set_cpus_allowed(task_t *p, cpumask_t new_mask)
 {
-	if (!cpus_intersects(new_mask, cpu_online_map))
+	if (!cpu_isset(0, new_mask))
 		return -EINVAL;
 	return 0;
 }

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.650.933.1373, 1.925.600.0401

Re: [PATCH] sched hardcode non-smp set_cpus_allowed

[Rusty Russell]

On Thu, 2005-10-27 at 01:53 -0700, Paul Jackson wrote:
> @@ -945,7 +945,7 @@ extern int set_cpus_allowed(task_t *p, c
>  #else
>  static inline int set_cpus_allowed(task_t *p, cpumask_t new_mask)
>  {
> -	if (!cpus_intersects(new_mask, cpu_online_map))
> +	if (!cpu_isset(0, new_mask))
>  		return -EINVAL;
>  	return 0;
>  }

Hmm, I do slightly prefer the former, since it is exactly the same as
the SMP case, and doesn't hardcode 0.  Perhaps worth making
cpu_online_map a literal "1" for the UP case, which will help
everywhere.  With our include web, however, that might be tricky.

Rusty.
-- 
A bad analogy is like a leaky screwdriver -- Richard Braakman

Re: [PATCH] sched hardcode non-smp set_cpus_allowed

[Paul Jackson]

Rusty wrote:
> Hmm, I do slightly prefer the former, since it is exactly the same as
> the SMP case,

I tend to agree with that, in theory.

But the cpu_online_map reference had broken some (driver, module, ...?)
that had wasted a bit of Andrew's time, which was worth something to me
as well.  I was more than happy to make a one-line change if it removed
a small pothole on Andrew's road.

We've got a couple of schools of thought here ... at least.

I tend to prefer having the source code express the general case, and
then using header file magic to optimize the generated code for the uni-
processor systems.  I guess this would be Rusty-style source code,
Andrew-style machine code, and esoteric style headers.

> With our include web, however, that might be tricky.

Yeah.  Not worth messing with, in my book.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.925.600.0401