Hello,
After upgrading a quad-socket quad-core machine from 2.6.27 to 2.6.29,
numactl now reports that --physcpubind=X is an out-of-range CPU when
12<=X<16
(while obviously we still have 16 cores in this machine).
Same problem on other machines with 2.6.29: the last 4 cores are
"out-of-range".
First observed with Debian's 2.0.3-rc1 but seems to occur with 2.0.3-rc2
as well.
It appears that this is caused by set_thread_constraints() passing a
wrong pointer to read_mask() when trying to gather maxproccpu and
maxprocnode from /proc/self/status. It points to the second character
of the mask instead of the first one, thus loosing one "f", which means
4 cores are lost.
The kernel code generating the "Cpus_allowed:" and "Mems_allowed:" masks
in /proc/self/status has changed recently, so maybe the formatting
changed a bit (whitespaces?).
The patch below fixes this problem by just passing a pointer to the first
character after ":". read_mask/strtoul are able to skip whitespaces anyway,
so no need to bother trying to guess how many whitespaces follow ":" in the
caller.
Brice
Signed-off-by: Brice Goglin <Brice.Goglin@xxxxxxxx>
diff -ur numactl-2.0.3~rc1/libnuma.c numactl-2.0.3~rc1.save/libnuma.c
--- numactl-2.0.3~rc1/libnuma.c 2008-12-09 20:38:07.000000000 +0100
+++ numactl-2.0.3~rc1.save/libnuma.c 2009-04-21 15:44:19.000000000 +0200
@@ -479,11 +479,11 @@
while (getline(&buffer, &buflen, f) > 0) {
if (strncmp(buffer,"Cpus_allowed:",13) == 0)
- maxproccpu = read_mask(buffer + 15, numa_all_cpus_ptr);
+ maxproccpu = read_mask(buffer + 13, numa_all_cpus_ptr);
if (strncmp(buffer,"Mems_allowed:",13) == 0) {
maxprocnode =
- read_mask(buffer + 15, numa_all_nodes_ptr);
+ read_mask(buffer + 13, numa_all_nodes_ptr);
}
}
fclose(f);
--
To unsubscribe from this list: send the line "unsubscribe linux-numa" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
