From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753367AbdDJMni (ORCPT <rfc822;w@1wt.eu>);
        Mon, 10 Apr 2017 08:43:38 -0400
Received: from mail.skyhub.de ([5.9.137.197]:60772 "EHLO mail.skyhub.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1753165AbdDJMng (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Mon, 10 Apr 2017 08:43:36 -0400
Date: Mon, 10 Apr 2017 14:43:20 +0200
From: Borislav Petkov <bp@alien8.de>
To: Wei Yang <richard.weiyang@gmail.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Tejun Heo <tj@kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [Patch V2 2/2] x86/mm/numa: remove the
 numa_nodemask_from_meminfo()
Message-ID: <20170410124320.fq5sw4lt2imztiyl@pd.tnic>
References: <20170314030801.13656-1-richard.weiyang@gmail.com>
 <20170314030801.13656-2-richard.weiyang@gmail.com>
 <20170406124459.dwn5zhpr2xqg3lqm@node.shutemov.name>
 <20170406145937.docce7sa5tuqyon4@pd.tnic>
 <20170406154216.a4um6ftjyia5wxya@node.shutemov.name>
 <20170406180113.hvcydzrjldodosfo@pd.tnic>
 <20170406182147.mwifrukq7ylczi6i@node.shutemov.name>
 <20170406184838.z4pa4j33z2rp4mrg@pd.tnic>
 <CADZGycaQpigWOsDBikGgn_xJ9SXCA+WLRL_z=CHGiB4yi+GVYw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CADZGycaQpigWOsDBikGgn_xJ9SXCA+WLRL_z=CHGiB4yi+GVYw@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Apr 09, 2017 at 11:12:14AM +0800, Wei Yang wrote:
> Oops, sorry to bring in the regression with my cleanup.
> I haven't noticed there is a kernel command line "numa=fake", which
> is the cause of the crash I think.

Of course it is, didn't you see my debugging upthread?

> So from my understanding, I am goting to do these tests:
> 
> 1. all fake numa scenarios with Kirill's qemu command line

It is enough if you boot the kernel with "numa=fake..."

> 2. Real numa scenarios with following qemu command option

Not qemu command option but a kernel cmdline option.

> 3. Baremetal
> 
> One more question, on the baremetal mathine, I can't change the
> numa configuration, so there would be only one case. Do you have
> some specific requirement?

numa=fake on baremetal too.

> Well, if I missed something, just let me know :-)
> 
> > Qemu can emulate real numa too, for example you can boot with:
> >
> > -smp 64 \
> > -numa node,nodeid=0,cpus=1-8 \
> > -numa node,nodeid=1,cpus=9-16 \
> > -numa node,nodeid=2,cpus=17-24 \
> > -numa node,nodeid=3,cpus=25-32 \
> > -numa node,nodeid=4,cpus=0 \
> > -numa node,nodeid=4,cpus=33-39 \
> > -numa node,nodeid=5,cpus=40-47 \
> > -numa node,nodeid=6,cpus=48-55 \
> > -numa node,nodeid=7,cpus=56-63

Also, do this in kvm. kvm can emulate a lot of numa configurations, do
experiment with those too.

Basically, try to break your "cleanup". Stuff one should do for every
patch one sends anyway.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.