lkml.org 
[lkml]   [2017]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 1/1] mm: only dispaly online cpus of the numa node
On Tue 03-10-17 14:47:26, Will Deacon wrote:
> On Mon, Oct 02, 2017 at 02:54:46PM -0700, Andrew Morton wrote:
> > On Mon, 2 Oct 2017 11:38:07 +0100 Will Deacon <will.deacon@arm.com> wrote:
> >
> > > > When I executed numactl -H(which read /sys/devices/system/node/nodeX/cpumap
> > > > and display cpumask_of_node for each node), but I got different result on
> > > > X86 and arm64. For each numa node, the former only displayed online CPUs,
> > > > and the latter displayed all possible CPUs. Unfortunately, both Linux
> > > > documentation and numactl manual have not described it clear.
> > > >
> > > > I sent a mail to ask for help, and Michal Hocko <mhocko@kernel.org> replied
> > > > that he preferred to print online cpus because it doesn't really make much
> > > > sense to bind anything on offline nodes.
> > > >
> > > > Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> > > > Acked-by: Michal Hocko <mhocko@suse.com>
> > > > ---
> > > > drivers/base/node.c | 12 ++++++++++--
> > > > 1 file changed, 10 insertions(+), 2 deletions(-)
> > >
> > > Which tree is this intended to go through? I'm happy to take it via arm64,
> > > but I don't want to tread on anybody's toes in linux-next and it looks like
> > > there are already queued changes to this file via Andrew's tree.
> >
> > I grabbed it. I suppose there's some small risk of userspace breakage
> > so I suggest it be a 4.15-rc1 thing?
>
> To be honest, I suspect the vast majority (if not all) code that reads this
> file was developed for x86, so having the same behaviour for arm64 sounds
> like something we should do ASAP before people try to special case with
> things like #ifdef __aarch64__.
>
> I'd rather have this in 4.14 if possible.

Agreed!

--
Michal Hocko
SUSE Labs

\
 
 \ /
  Last update: 2017-10-03 15:57    [W:0.093 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site