Re: 2.6.16 - sys_sched_getaffinity & hotplug

[Nathan Lynch <ntl@pobox.com>]

Jack Steiner wrote:
> 
> It appears if CONFIG_HOTPLUG_CPU is enabled, then all possible
> cpus (0 .. NR_CPUS-1) are set in the cpu_possible_map on IA64.

That's too bad...


> sched_getaffinity() returns the cpu_possible_map and'd with the current
> task p->cpus_allowed. The default cpus_allowed is all ones.
> 
> This is causing problems for apps that use sched_get_sched_affinity()
> to determine which cpus that they are allowed to run on.

How?  Are these apps expecting all set bits to correspond to online
cpus?


> The call to sched_getaffinity returns:
> 
> 	(from strace on a 2 cpu system with NR_CPUS = 512)
> 	sched_getaffinity(0, 1024,  { ffffffffffffffff, ffffff ...
> 
> 
> 
> The man page for sched_getaffinity() is ambiguous. It says:
> 	- A set bit corresponds to a legally  schedulable  CPU
> 
> But it also says:
> 	- Usually, all bits in the mask are set.
> 
> 
> Should the following change be made to sched_getaffinity(). 
> 
> Index: linux/kernel/sched.c
> ===================================================================
> --- linux.orig/kernel/sched.c	2006-01-25 08:50:21.401747695 -0600
> +++ linux/kernel/sched.c	2006-01-27 16:57:24.504871895 -0600
> @@ -4031,7 +4031,7 @@ long sched_getaffinity(pid_t pid, cpumas
>  		goto out_unlock;
>  
>  	retval = 0;
> -	cpus_and(*mask, p->cpus_allowed, cpu_possible_map);
> +	cpus_and(*mask, p->cpus_allowed, cpu_online_map);


I don't think so.

For one, that would be mucking around with a kernel/userspace ABI, I
guess.

Additionally, it would mean that the result of sched_getaffinity would
vary with the number of online cpus in the system, which I don't think
is desirable.
-
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/