Hi Petr, On Tue, Oct 23, 2012 at 02:21:40PM +0200, Petr Holasek wrote: > Hi everyone, > > On Mon, 22 Oct 2012, Jon Stanley wrote: > > On Mon, Oct 22, 2012 at 3:41 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote: > > > That was done intentional at some point to handle cpusets. > > > numactl 1.0 or so didn't have that problem. > > > > I'll happily admit to not being an expert here :) > > I've added new interface for parsing cpusets/nodesets with _all() suffix > in 2.0.8-rc5 libnuma, but numactl utility still uses old ones with cpuset > awareness. I didn't want to dig into some libnuma internals and change > behaviour of dependent utils in such way. > > > > > However, I thought that the concept of cpusets was that if you > > attempted to set affinity outside of your cpuset, that would silently > > fail. I assume that the reason that libnuma didn't want to set outside > > of it's own affinity mask is to avoid such a silent failure? > > > > Also, I question the Real World(TM) prevalence of cpusets. > > > > > However it's unclear if it's really bug. > > > > Not sure if I'd call it a bug since it was intentional, but sure would > > call it an unexpected change in behavior :) > > I like the idea of some overriding option proposed by Andi. > > btw, Cliff, can you remember what was the reason for this change in some > version after 1.0? > > Petr Memory nodes allowed was made cpuset-aware by the below patch. I'm not quite sure if this is the change you are asking about. patch 0804_ls_patch2 From: Lee Schermerhorn <lee.schermerhorn@xxxxxx> Date: Wed, 02 Apr 2008 14:34:37 -0400 Depends-on: MPOL_F_MEMS_ALLOWED kernel patch Provide libnuma API for MPOL_F_MEMS_ALLOWED flag. Return nodes allowed by the application's current cpuset context via new API numa_get_mems_allowed(). +.BR numa_get_mems_allowed() +returns the mask of nodes from which the process is allowed to allocate +memory in it's current cpuset context. -Cliff -- Cliff Wickman SGI cpw@xxxxxxx (651) 683-3824 -- 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