lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Wed, 20 Nov 2019 08:13:18 -0800
From:   Randy Dunlap <rdunlap@...radead.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yoshinori Sato <ysato@...rs.sourceforge.jp>,
        Rich Felker <dalias@...c.org>,
        Linux-sh list <linux-sh@...r.kernel.org>
Subject: Re: [PATCH] arch/sh/: fix NUMA build errors

On 11/20/19 12:30 AM, Geert Uytterhoeven wrote:
> Hi Randy,
> 
> On Wed, Nov 20, 2019 at 5:28 AM Randy Dunlap <rdunlap@...radead.org> wrote:
>> On 11/18/19 11:38 PM, Geert Uytterhoeven wrote:
>>> On Tue, Nov 19, 2019 at 1:55 AM Randy Dunlap <rdunlap@...radead.org> wrote:
>>>> From: Randy Dunlap <rdunlap@...radead.org>
>>>> Fix SUPERH builds that select SYS_SUPPORTS_NUMA but do not select
>>>> SYS_SUPPORTS_SMP and SMP.
>>>>
>>>> kernel/sched/topology.c is only built for CONFIG_SMP and then the NUMA
>>>> code + data inside topology.c is only built when CONFIG_NUMA is
>>>> set/enabled, so these arch/sh/ configs need to select SMP and
>>>> SYS_SUPPORTS_SMP to build the NUMA support.
>>>>
>>>> Fixes this build error in 3 different SUPERH configs:
>>>>
>>>> mm/page_alloc.o: In function `get_page_from_freelist':
>>>> page_alloc.c:(.text+0x2ca8): undefined reference to `node_reclaim_distance'
>>>>
>>>> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
>>>> Reported-by: Geert Uytterhoeven <geert@...ux-m68k.org>
>>>> Cc: Yoshinori Sato <ysato@...rs.sourceforge.jp>
>>>> Cc: Rich Felker <dalias@...c.org>
>>>> Cc: linux-sh@...r.kernel.org
>>>> ---
>>>> or maybe these should be fixed in the defconfig files?
>>>>
>>>> or alternatively, does it make any sense to support NUMA without SMP?
>>>
>>> I think it does.  From arch/sh/mm/Kconfig config NUMA help:
>>>
>>>         Some SH systems have many various memories scattered around
>>>         the address space, each with varying latencies. This enables
>>>         support for these blocks by binding them to nodes and allowing
>>>         memory policies to be used for prioritizing and controlling
>>>         allocation behaviour.
>>
>> Note that this help text is under:
>> config NUMA
>>         bool "Non-Uniform Memory Access (NUMA) Support"
>>         depends on MMU && SYS_SUPPORTS_NUMA
>>         select ARCH_WANT_NUMA_VARIABLE_LOCALITY
>>
>> but ARCH_WANT_NUMA_VARIABLE_LOCALITY seems to be unimplemented anywhere in
>> the kernel source tree.  I.e., the Kconfig symbol exists in init/Kconfig,
>> but there is no code to support its use.
> 
> It does control (prevent) another option:
> 
> # For architectures that (ab)use NUMA to represent different memory regions
> # all cpu-local but of different latencies, such as SuperH.
> #
> config ARCH_WANT_NUMA_VARIABLE_LOCALITY
>         bool
> 
> config NUMA_BALANCING
>         bool "Memory placement aware NUMA scheduler"
>         depends on ARCH_SUPPORTS_NUMA_BALANCING
>         depends on !ARCH_WANT_NUMA_VARIABLE_LOCALITY
>         depends on SMP && NUMA && MIGRATION
>         help
>           This option adds support for automatic NUMA aware
> memory/task placement.
>           The mechanism is quite primitive and is based on migrating memory when
>           it has references to the node the task is running on.
> 
>           This system will be inactive on UMA systems.
> 
> The symbol was set by arch/metag, too (which was removed).

I see.  thanks.

-- 
~Randy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ