a927bd6ba9
The core-mm has a default __weak implementation of phys_to_target_node()
to mirror the weak definition of memory_add_physaddr_to_nid(). That
symbol is exported for modules. However, while the export in
mm/memory_hotplug.c exported the symbol in the configuration cases of:
CONFIG_NUMA_KEEP_MEMINFO=y
CONFIG_MEMORY_HOTPLUG=y
...and:
CONFIG_NUMA_KEEP_MEMINFO=n
CONFIG_MEMORY_HOTPLUG=y
...it failed to export the symbol in the case of:
CONFIG_NUMA_KEEP_MEMINFO=y
CONFIG_MEMORY_HOTPLUG=n
Not only is that broken, but Christoph points out that the kernel should
not be exporting any __weak symbol, which means that
memory_add_physaddr_to_nid() example that phys_to_target_node() copied
is broken too.
Rework the definition of phys_to_target_node() and
memory_add_physaddr_to_nid() to not require weak symbols. Move to the
common arch override design-pattern of an asm header defining a symbol
to replace the default implementation.
The only common header that all memory_add_physaddr_to_nid() producing
architectures implement is asm/sparsemem.h. In fact, powerpc already
defines its memory_add_physaddr_to_nid() helper in sparsemem.h.
Double-down on that observation and define phys_to_target_node() where
necessary in asm/sparsemem.h. An alternate consideration that was
discarded was to put this override in asm/numa.h, but that entangles
with the definition of MAX_NUMNODES relative to the inclusion of
linux/nodemask.h, and requires powerpc to grow a new header.
The dependency on NUMA_KEEP_MEMINFO for DEV_DAX_HMEM_DEVICES is invalid
now that the symbol is properly exported / stubbed in all combinations
of CONFIG_NUMA_KEEP_MEMINFO and CONFIG_MEMORY_HOTPLUG.
[dan.j.williams@intel.com: v4]
Link: https://lkml.kernel.org/r/160461461867.1505359.5301571728749534585.stgit@dwillia2-desk3.amr.corp.intel.com
[dan.j.williams@intel.com: powerpc: fix create_section_mapping compile warning]
Link: https://lkml.kernel.org/r/160558386174.2948926.2740149041249041764.stgit@dwillia2-desk3.amr.corp.intel.com
Fixes: a035b6bf86 ("mm/memory_hotplug: introduce default phys_to_target_node() implementation")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Cc: Joao Martins <joao.m.martins@oracle.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Vishal Verma <vishal.l.verma@intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lkml.kernel.org/r/160447639846.1133764.7044090803980177548.stgit@dwillia2-desk3.amr.corp.intel.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
83 lines
2.6 KiB
Plaintext
83 lines
2.6 KiB
Plaintext
# SPDX-License-Identifier: GPL-2.0-only
|
|
config DAX_DRIVER
|
|
select DAX
|
|
bool
|
|
|
|
menuconfig DAX
|
|
tristate "DAX: direct access to differentiated memory"
|
|
select SRCU
|
|
default m if NVDIMM_DAX
|
|
|
|
if DAX
|
|
|
|
config DEV_DAX
|
|
tristate "Device DAX: direct access mapping device"
|
|
depends on TRANSPARENT_HUGEPAGE
|
|
help
|
|
Support raw access to differentiated (persistence, bandwidth,
|
|
latency...) memory via an mmap(2) capable character
|
|
device. Platform firmware or a device driver may identify a
|
|
platform memory resource that is differentiated from the
|
|
baseline memory pool. Mappings of a /dev/daxX.Y device impose
|
|
restrictions that make the mapping behavior deterministic.
|
|
|
|
config DEV_DAX_PMEM
|
|
tristate "PMEM DAX: direct access to persistent memory"
|
|
depends on LIBNVDIMM && NVDIMM_DAX && DEV_DAX
|
|
default DEV_DAX
|
|
help
|
|
Support raw access to persistent memory. Note that this
|
|
driver consumes memory ranges allocated and exported by the
|
|
libnvdimm sub-system.
|
|
|
|
Say M if unsure
|
|
|
|
config DEV_DAX_HMEM
|
|
tristate "HMEM DAX: direct access to 'specific purpose' memory"
|
|
depends on EFI_SOFT_RESERVE
|
|
select NUMA_KEEP_MEMINFO if (NUMA && X86)
|
|
default DEV_DAX
|
|
help
|
|
EFI 2.8 platforms, and others, may advertise 'specific purpose'
|
|
memory. For example, a high bandwidth memory pool. The
|
|
indication from platform firmware is meant to reserve the
|
|
memory from typical usage by default. This driver creates
|
|
device-dax instances for these memory ranges, and that also
|
|
enables the possibility to assign them to the DEV_DAX_KMEM
|
|
driver to override the reservation and add them to kernel
|
|
"System RAM" pool.
|
|
|
|
Say M if unsure.
|
|
|
|
config DEV_DAX_HMEM_DEVICES
|
|
depends on DEV_DAX_HMEM && DAX=y
|
|
def_bool y
|
|
|
|
config DEV_DAX_KMEM
|
|
tristate "KMEM DAX: volatile-use of persistent memory"
|
|
default DEV_DAX
|
|
depends on DEV_DAX
|
|
depends on MEMORY_HOTPLUG # for add_memory() and friends
|
|
help
|
|
Support access to persistent, or other performance
|
|
differentiated memory as if it were System RAM. This allows
|
|
easier use of persistent memory by unmodified applications, or
|
|
adds core kernel memory services to heterogeneous memory types
|
|
(HMEM) marked "reserved" by platform firmware.
|
|
|
|
To use this feature, a DAX device must be unbound from the
|
|
device_dax driver and bound to this kmem driver on each boot.
|
|
|
|
Say N if unsure.
|
|
|
|
config DEV_DAX_PMEM_COMPAT
|
|
tristate "PMEM DAX: support the deprecated /sys/class/dax interface"
|
|
depends on m && DEV_DAX_PMEM=m
|
|
default DEV_DAX_PMEM
|
|
help
|
|
Older versions of the libdaxctl library expect to find all
|
|
device-dax instances under /sys/class/dax. If libdaxctl in
|
|
your distribution is older than v58 say M, otherwise say N.
|
|
|
|
endif
|