From mboxrd@z Thu Jan 1 00:00:00 1970 From: Petr Holasek Subject: Re: numactl using it's own affinity to determine CPU set Date: Tue, 23 Oct 2012 14:21:40 +0200 Message-ID: <20121023122139.GA5766@machinehead.brq.redhat.com> References: <20121022194141.GT16230@one.firstfloor.org> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-numa-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Jon Stanley Cc: Andi Kleen , linux-numa@vger.kernel.org, Cliff Wickman Hi everyone, On Mon, 22 Oct 2012, Jon Stanley wrote: > On Mon, Oct 22, 2012 at 3:41 PM, Andi Kleen 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