From: Kefeng Wang <wangkefeng.wang@huawei.com>
To: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Atish Patra <Atish.Patra@wdc.com>,
<linux-riscv@lists.infradead.org>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH -next] RISCV: Add some depends for NUMA
Date: Fri, 5 Feb 2021 15:53:21 +0800 [thread overview]
Message-ID: <ed095f07-8c91-903b-2859-203ca9b429fa@huawei.com> (raw)
In-Reply-To: <mhng-3a9465c0-42bb-42de-ad66-855dc2e3c56f@palmerdabbelt-glaptop>
On 2021/2/5 14:58, Palmer Dabbelt wrote:
> On Wed, 03 Feb 2021 06:23:43 PST (-0800), wangkefeng.wang@huawei.com
> wrote:
>> The numa feature is useless for riscv32 platform(MAXPHYSMEM_1GB if
>> 32bit),
>
> I'm not convinced of that. There's no reason NUMA shouldn't work on
> 32-bit, it
> doesn't depend on having a large amount of memory just having non-uniform
> memory. I could buy the argument that build a 32-bit NUMA system
> would be
> wacky, but IIUC it works now and I don't see any reason to throw that
> away.
I think the RV32 won't benefit from NUMA, there's no too much memory
support on RV32,
and it may increase the Image size, so I decided to drop support for RV32.
>
>> and it should depends on SMP feature, this also fix the build error,
>
> I can buy that CONFIG_NUMA doesn't really make sense without
> CONFIG_SMP, as
> there's not a whole lot to do, but I also don't see any reason from
> disallowing
> users from picking it. arm64 allows !SMP && NUMA, and I don't see any
> reason
> it wouldn't work just as well for us.
ARM64 won' support !SMP after following patch, and for most
architecture, the NUMA feature
depends or select SMP feature.
commit 4b3dc9679cf779339d9049800803dfc3c83433d1
Author: Will Deacon <will@kernel.org>
Date: Fri May 29 18:28:44 2015 +0100
arm64: force CONFIG_SMP=y and remove redundant #ifdefs
>
>> riscv64-buildroot-linux-gnu-ld: mm/page_alloc.o: in function `.L0 ':
>> page_alloc.c:(.text+0x4808): undefined reference to
>> `node_reclaim_distance'
>
> The only instance of node_reclaim_distance I see in mm/page_alloc.c is
> already
> guarded with CONFIG_NUMA, but the definition of node_reclaim_distance
> isn't.
> I'll send out some patches to add the guard which might make sorting
> this out
> earlier, but I don't see it fixing any failures.
>
>
>
prev parent reply other threads:[~2021-02-05 7:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-03 14:23 Kefeng Wang
2021-02-03 19:59 ` Atish Patra
2021-02-04 9:17 ` Kefeng Wang
2021-02-05 6:58 ` Palmer Dabbelt
2021-02-05 7:53 ` Kefeng Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ed095f07-8c91-903b-2859-203ca9b429fa@huawei.com \
--to=wangkefeng.wang@huawei.com \
--cc=Atish.Patra@wdc.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®