Messages in this thread | | | Date | Fri, 27 Jan 2006 20:58:55 -0600 | From | Nathan Lynch <> | Subject | Re: 2.6.16 - sys_sched_getaffinity & hotplug |
| |
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/
| |