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 S1751992AbdDIDMo (ORCPT <rfc822;w@1wt.eu>);
        Sat, 8 Apr 2017 23:12:44 -0400
Received: from mail-oi0-f65.google.com ([209.85.218.65]:36319 "EHLO
        mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751348AbdDIDMf (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Sat, 8 Apr 2017 23:12:35 -0400
MIME-Version: 1.0
In-Reply-To: <20170406184838.z4pa4j33z2rp4mrg@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>
From: Wei Yang <richard.weiyang@gmail.com>
Date: Sun, 9 Apr 2017 11:12:14 +0800
Message-ID: <CADZGycaQpigWOsDBikGgn_xJ9SXCA+WLRL_z=CHGiB4yi+GVYw@mail.gmail.com>
Subject: Re: [Patch V2 2/2] x86/mm/numa: remove the numa_nodemask_from_meminfo()
To: Borislav Petkov <bp@alien8.de>
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>
Content-Type: text/plain; charset=UTF-8
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, Apr 7, 2017 at 2:48 AM, Borislav Petkov <bp@alien8.de> wrote:
> On Thu, Apr 06, 2017 at 09:21:47PM +0300, Kirill A. Shutemov wrote:
>> > Long story short, something as trivial as this helps here:
>>
>> Yep. Works for me.
>>
>> Reported-and-tested-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
>
> Thanks.
>
> Now, I'd really like to have more test coverage and be sure this
> "cleanup" doesn't break anything else so Wei, please grab tip/master,
> apply the oneliner from two messages ago, take Kirill's qemu cmdline
> and run all fake numa scenarios you can think of to make sure your
> cleanup doesn't break anything else.
>

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.

So from my understanding, I am goting to do these tests:

1. all fake numa scenarios with Kirill's qemu command line
2. Real numa scenarios with following qemu command 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?

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
>
> after configuring the kernel accordingly.
>
> Then, test baremetal too.
>
> numa_emulation() should give you an idea about possible options
> numa=fake takes. Documentation/x86/x86_64/boot-options.txt has some
> (all?) too.
>
> Thanks.
>
> --
> Regards/Gruss,
>     Boris.
>
> Good mailing practices for 400: avoid top-posting and trim the reply.