2017-07-13 03:58:21 +03:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
/* Copyright(c) 2016 - 2018 Intel Corporation. All rights reserved. */
|
|
|
|
|
#ifndef __DAX_BUS_H__
|
|
|
|
|
#define __DAX_BUS_H__
|
2017-07-16 23:51:53 +03:00
|
|
|
#include <linux/device.h>
|
2020-10-14 02:49:43 +03:00
|
|
|
#include <linux/range.h>
|
2017-07-16 23:51:53 +03:00
|
|
|
|
2017-07-13 03:58:21 +03:00
|
|
|
struct dev_dax;
|
|
|
|
|
struct resource;
|
|
|
|
|
struct dax_device;
|
|
|
|
|
struct dax_region;
|
|
|
|
|
void dax_region_put(struct dax_region *dax_region);
|
2020-10-14 02:50:03 +03:00
|
|
|
|
dax: Assign RAM regions to memory-hotplug by default
The default mode for device-dax instances is backwards for RAM-regions
as evidenced by the fact that it tends to catch end users by surprise.
"Where is my memory?". Recall that platforms are increasingly shipping
with performance-differentiated memory pools beyond typical DRAM and
NUMA effects. This includes HBM (high-bandwidth-memory) and CXL (dynamic
interleave, varied media types, and future fabric attached
possibilities).
For this reason the EFI_MEMORY_SP (EFI Special Purpose Memory => Linux
'Soft Reserved') attribute is expected to be applied to all memory-pools
that are not the general purpose pool. This designation gives an
Operating System a chance to defer usage of a memory pool until later in
the boot process where its performance properties can be interrogated
and administrator policy can be applied.
'Soft Reserved' memory can be anything from too limited and precious to
be part of the general purpose pool (HBM), too slow to host hot kernel
data structures (some PMEM media), or anything in between. However, in
the absence of an explicit policy, the memory should at least be made
usable by default. The current device-dax default hides all
non-general-purpose memory behind a device interface.
The expectation is that the distribution of users that want the memory
online by default vs device-dedicated-access by default follows the
Pareto principle. A small number of enlightened users may want to do
userspace memory management through a device, but general users just
want the kernel to make the memory available with an option to get more
advanced later.
Arrange for all device-dax instances not backed by PMEM to default to
attaching to the dax_kmem driver. From there the baseline memory hotplug
policy (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE / memhp_default_state=)
gates whether the memory comes online or stays offline. Where, if it
stays offline, it can be reliably converted back to device-mode where it
can be partitioned, or fronted by a userspace allocator.
So, if someone wants device-dax instances for their 'Soft Reserved'
memory:
1/ Build a kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n or boot
with memhp_default_state=offline, or roll the dice and hope that the
kernel has not pinned a page in that memory before step 2.
2/ Write a udev rule to convert the target dax device(s) from
'system-ram' mode to 'devdax' mode:
daxctl reconfigure-device $dax -m devdax -f
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Gregory Price <gregory.price@memverge.com>
Tested-by: Fan Ni <fan.ni@samsung.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/167602003336.1924368.6809503401422267885.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-02-10 12:07:13 +03:00
|
|
|
/* dax bus specific ioresource flags */
|
|
|
|
|
#define IORESOURCE_DAX_STATIC BIT(0)
|
|
|
|
|
#define IORESOURCE_DAX_KMEM BIT(1)
|
|
|
|
|
|
2017-07-13 03:58:21 +03:00
|
|
|
struct dax_region *alloc_dax_region(struct device *parent, int region_id,
|
2020-10-14 02:50:29 +03:00
|
|
|
struct range *range, int target_node, unsigned int align,
|
2020-10-14 02:50:03 +03:00
|
|
|
unsigned long flags);
|
2017-07-16 23:51:53 +03:00
|
|
|
|
2020-10-14 02:49:38 +03:00
|
|
|
struct dev_dax_data {
|
|
|
|
|
struct dax_region *dax_region;
|
|
|
|
|
struct dev_pagemap *pgmap;
|
2020-10-14 02:50:03 +03:00
|
|
|
resource_size_t size;
|
2020-10-14 02:49:38 +03:00
|
|
|
int id;
|
|
|
|
|
};
|
2017-07-16 23:51:53 +03:00
|
|
|
|
2020-10-14 02:49:38 +03:00
|
|
|
struct dev_dax *devm_create_dev_dax(struct dev_dax_data *data);
|
2017-07-16 23:51:53 +03:00
|
|
|
|
dax: Assign RAM regions to memory-hotplug by default
The default mode for device-dax instances is backwards for RAM-regions
as evidenced by the fact that it tends to catch end users by surprise.
"Where is my memory?". Recall that platforms are increasingly shipping
with performance-differentiated memory pools beyond typical DRAM and
NUMA effects. This includes HBM (high-bandwidth-memory) and CXL (dynamic
interleave, varied media types, and future fabric attached
possibilities).
For this reason the EFI_MEMORY_SP (EFI Special Purpose Memory => Linux
'Soft Reserved') attribute is expected to be applied to all memory-pools
that are not the general purpose pool. This designation gives an
Operating System a chance to defer usage of a memory pool until later in
the boot process where its performance properties can be interrogated
and administrator policy can be applied.
'Soft Reserved' memory can be anything from too limited and precious to
be part of the general purpose pool (HBM), too slow to host hot kernel
data structures (some PMEM media), or anything in between. However, in
the absence of an explicit policy, the memory should at least be made
usable by default. The current device-dax default hides all
non-general-purpose memory behind a device interface.
The expectation is that the distribution of users that want the memory
online by default vs device-dedicated-access by default follows the
Pareto principle. A small number of enlightened users may want to do
userspace memory management through a device, but general users just
want the kernel to make the memory available with an option to get more
advanced later.
Arrange for all device-dax instances not backed by PMEM to default to
attaching to the dax_kmem driver. From there the baseline memory hotplug
policy (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE / memhp_default_state=)
gates whether the memory comes online or stays offline. Where, if it
stays offline, it can be reliably converted back to device-mode where it
can be partitioned, or fronted by a userspace allocator.
So, if someone wants device-dax instances for their 'Soft Reserved'
memory:
1/ Build a kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n or boot
with memhp_default_state=offline, or roll the dice and hope that the
kernel has not pinned a page in that memory before step 2.
2/ Write a udev rule to convert the target dax device(s) from
'system-ram' mode to 'devdax' mode:
daxctl reconfigure-device $dax -m devdax -f
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Gregory Price <gregory.price@memverge.com>
Tested-by: Fan Ni <fan.ni@samsung.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/167602003336.1924368.6809503401422267885.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-02-10 12:07:13 +03:00
|
|
|
enum dax_driver_type {
|
|
|
|
|
DAXDRV_KMEM_TYPE,
|
|
|
|
|
DAXDRV_DEVICE_TYPE,
|
|
|
|
|
};
|
|
|
|
|
|
2018-11-08 02:31:23 +03:00
|
|
|
struct dax_device_driver {
|
|
|
|
|
struct device_driver drv;
|
|
|
|
|
struct list_head ids;
|
dax: Assign RAM regions to memory-hotplug by default
The default mode for device-dax instances is backwards for RAM-regions
as evidenced by the fact that it tends to catch end users by surprise.
"Where is my memory?". Recall that platforms are increasingly shipping
with performance-differentiated memory pools beyond typical DRAM and
NUMA effects. This includes HBM (high-bandwidth-memory) and CXL (dynamic
interleave, varied media types, and future fabric attached
possibilities).
For this reason the EFI_MEMORY_SP (EFI Special Purpose Memory => Linux
'Soft Reserved') attribute is expected to be applied to all memory-pools
that are not the general purpose pool. This designation gives an
Operating System a chance to defer usage of a memory pool until later in
the boot process where its performance properties can be interrogated
and administrator policy can be applied.
'Soft Reserved' memory can be anything from too limited and precious to
be part of the general purpose pool (HBM), too slow to host hot kernel
data structures (some PMEM media), or anything in between. However, in
the absence of an explicit policy, the memory should at least be made
usable by default. The current device-dax default hides all
non-general-purpose memory behind a device interface.
The expectation is that the distribution of users that want the memory
online by default vs device-dedicated-access by default follows the
Pareto principle. A small number of enlightened users may want to do
userspace memory management through a device, but general users just
want the kernel to make the memory available with an option to get more
advanced later.
Arrange for all device-dax instances not backed by PMEM to default to
attaching to the dax_kmem driver. From there the baseline memory hotplug
policy (CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE / memhp_default_state=)
gates whether the memory comes online or stays offline. Where, if it
stays offline, it can be reliably converted back to device-mode where it
can be partitioned, or fronted by a userspace allocator.
So, if someone wants device-dax instances for their 'Soft Reserved'
memory:
1/ Build a kernel with CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=n or boot
with memhp_default_state=offline, or roll the dice and hope that the
kernel has not pinned a page in that memory before step 2.
2/ Write a udev rule to convert the target dax device(s) from
'system-ram' mode to 'devdax' mode:
daxctl reconfigure-device $dax -m devdax -f
Cc: Michal Hocko <mhocko@suse.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Gregory Price <gregory.price@memverge.com>
Tested-by: Fan Ni <fan.ni@samsung.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/167602003336.1924368.6809503401422267885.stgit@dwillia2-xfh.jf.intel.com
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2023-02-10 12:07:13 +03:00
|
|
|
enum dax_driver_type type;
|
2020-10-14 02:50:08 +03:00
|
|
|
int (*probe)(struct dev_dax *dev);
|
2021-02-06 01:28:42 +03:00
|
|
|
void (*remove)(struct dev_dax *dev);
|
2018-11-08 02:31:23 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int __dax_driver_register(struct dax_device_driver *dax_drv,
|
2017-07-13 03:58:21 +03:00
|
|
|
struct module *module, const char *mod_name);
|
|
|
|
|
#define dax_driver_register(driver) \
|
|
|
|
|
__dax_driver_register(driver, THIS_MODULE, KBUILD_MODNAME)
|
2018-11-08 02:31:23 +03:00
|
|
|
void dax_driver_unregister(struct dax_device_driver *dax_drv);
|
2017-07-13 03:58:21 +03:00
|
|
|
void kill_dev_dax(struct dev_dax *dev_dax);
|
2022-01-15 01:04:33 +03:00
|
|
|
bool static_dev_dax(struct dev_dax *dev_dax);
|
2017-07-13 03:58:21 +03:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* While run_dax() is potentially a generic operation that could be
|
|
|
|
|
* defined in include/linux/dax.h we don't want to grow any users
|
|
|
|
|
* outside of drivers/dax/
|
|
|
|
|
*/
|
|
|
|
|
void run_dax(struct dax_device *dax_dev);
|
|
|
|
|
|
|
|
|
|
#define MODULE_ALIAS_DAX_DEVICE(type) \
|
|
|
|
|
MODULE_ALIAS("dax:t" __stringify(type) "*")
|
|
|
|
|
#define DAX_DEVICE_MODALIAS_FMT "dax:t%d"
|
|
|
|
|
|
2017-07-13 03:58:21 +03:00
|
|
|
#endif /* __DAX_BUS_H__ */
|
