From: Ying Huang <ying.huang@intel.com>
To: Yang Shi <shy828301@gmail.com>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Linux MM <linux-mm@kvack.org>,
Andrew Morton <akpm@linux-foundation.org>,
Wei Xu <weixugc@google.com>, Greg Thelen <gthelen@google.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Tim C Chen <tim.c.chen@intel.com>,
Brice Goglin <brice.goglin@gmail.com>,
Michal Hocko <mhocko@kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Hesham Almatary <hesham.almatary@huawei.com>,
Dave Hansen <dave.hansen@intel.com>,
Jonathan Cameron <Jonathan.Cameron@huawei.com>,
Alistair Popple <apopple@nvidia.com>,
Dan Williams <dan.j.williams@intel.com>,
Feng Tang <feng.tang@intel.com>,
Jagdish Gediya <jvgediya@linux.ibm.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers
Date: Thu, 09 Jun 2022 14:52:58 +0800 [thread overview]
Message-ID: <287da19d187e816075e5772a22c63bdf9a5cb198.camel@intel.com> (raw)
In-Reply-To: <CAHbLzkoLr+RugZ4nq-HpVK2S3frnSor5MJPxRH4PsUPC-sfEGQ@mail.gmail.com>
On Wed, 2022-06-08 at 09:37 -0700, Yang Shi wrote:
> On Tue, Jun 7, 2022 at 6:34 PM Ying Huang <ying.huang@intel.com> wrote:
> >
> > On Tue, 2022-06-07 at 14:32 -0700, Yang Shi wrote:
> > > On Fri, Jun 3, 2022 at 6:43 AM Aneesh Kumar K.V
> > > <aneesh.kumar@linux.ibm.com> wrote:
> > > >
> > > > In the current kernel, memory tiers are defined implicitly via a
> > > > demotion path relationship between NUMA nodes, which is created
> > > > during the kernel initialization and updated when a NUMA node is
> > > > hot-added or hot-removed. The current implementation puts all
> > > > nodes with CPU into the top tier, and builds the tier hierarchy
> > > > tier-by-tier by establishing the per-node demotion targets based
> > > > on the distances between nodes.
> > > >
> > > > This current memory tier kernel interface needs to be improved for
> > > > several important use cases,
> > > >
> > > > The current tier initialization code always initializes
> > > > each memory-only NUMA node into a lower tier. But a memory-only
> > > > NUMA node may have a high performance memory device (e.g. a DRAM
> > > > device attached via CXL.mem or a DRAM-backed memory-only node on
> > > > a virtual machine) and should be put into a higher tier.
> > > >
> > > > The current tier hierarchy always puts CPU nodes into the top
> > > > tier. But on a system with HBM or GPU devices, the
> > > > memory-only NUMA nodes mapping these devices should be in the
> > > > top tier, and DRAM nodes with CPUs are better to be placed into the
> > > > next lower tier.
> > > >
> > > > With current kernel higher tier node can only be demoted to selected nodes on the
> > > > next lower tier as defined by the demotion path, not any other
> > > > node from any lower tier. This strict, hard-coded demotion order
> > > > does not work in all use cases (e.g. some use cases may want to
> > > > allow cross-socket demotion to another node in the same demotion
> > > > tier as a fallback when the preferred demotion node is out of
> > > > space), This demotion order is also inconsistent with the page
> > > > allocation fallback order when all the nodes in a higher tier are
> > > > out of space: The page allocation can fall back to any node from
> > > > any lower tier, whereas the demotion order doesn't allow that.
> > > >
> > > > The current kernel also don't provide any interfaces for the
> > > > userspace to learn about the memory tier hierarchy in order to
> > > > optimize its memory allocations.
> > > >
> > > > This patch series address the above by defining memory tiers explicitly.
> > > >
> > > > This patch introduce explicity memory tiers with ranks. The rank
> > > > value of a memory tier is used to derive the demotion order between
> > > > NUMA nodes. The memory tiers present in a system can be found at
> > > >
> > > > /sys/devices/system/memtier/memtierN/
> > > >
> > > > The nodes which are part of a specific memory tier can be listed
> > > > via
> > > > /sys/devices/system/memtier/memtierN/nodelist
> > > >
> > > > "Rank" is an opaque value. Its absolute value doesn't have any
> > > > special meaning. But the rank values of different memtiers can be
> > > > compared with each other to determine the memory tier order.
> > > >
> > > > For example, if we have 3 memtiers: memtier0, memtier1, memiter2, and
> > > > their rank values are 300, 200, 100, then the memory tier order is:
> > > > memtier0 -> memtier2 -> memtier1, where memtier0 is the highest tier
> > > > and memtier1 is the lowest tier.
> > > >
> > > > The rank value of each memtier should be unique.
> > > >
> > > > A higher rank memory tier will appear first in the demotion order
> > > > than a lower rank memory tier. ie. while reclaim we choose a node
> > > > in higher rank memory tier to demote pages to as compared to a node
> > > > in a lower rank memory tier.
> > > >
> > > > For now we are not adding the dynamic number of memory tiers.
> > > > But a future series supporting that is possible. Currently
> > > > number of tiers supported is limitted to MAX_MEMORY_TIERS(3).
> > > > When doing memory hotplug, if not added to a memory tier, the NUMA
> > > > node gets added to DEFAULT_MEMORY_TIER(1).
> > > >
> > > > This patch is based on the proposal sent by Wei Xu <weixugc@google.com> at [1].
> > > >
> > > > [1] https://lore.kernel.org/linux-mm/CAAPL-u9Wv+nH1VOZTj=9p9S70Y3Qz3+63EkqncRDdHfubsrjfw@mail.gmail.com
> > > >
> > > > Suggested-by: Wei Xu <weixugc@google.com>
> > > > Signed-off-by: Jagdish Gediya <jvgediya@linux.ibm.com>
> > > > Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
> > > > ---
> > > > include/linux/memory-tiers.h | 20 ++++
> > > > mm/Kconfig | 11 ++
> > > > mm/Makefile | 1 +
> > > > mm/memory-tiers.c | 188 +++++++++++++++++++++++++++++++++++
> > > > 4 files changed, 220 insertions(+)
> > > > create mode 100644 include/linux/memory-tiers.h
> > > > create mode 100644 mm/memory-tiers.c
> > > >
> > > > diff --git a/include/linux/memory-tiers.h b/include/linux/memory-tiers.h
> > > > new file mode 100644
> > > > index 000000000000..e17f6b4ee177
> > > > --- /dev/null
> > > > +++ b/include/linux/memory-tiers.h
> > > > @@ -0,0 +1,20 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +#ifndef _LINUX_MEMORY_TIERS_H
> > > > +#define _LINUX_MEMORY_TIERS_H
> > > > +
> > > > +#ifdef CONFIG_TIERED_MEMORY
> > > > +
> > > > +#define MEMORY_TIER_HBM_GPU 0
> > > > +#define MEMORY_TIER_DRAM 1
> > > > +#define MEMORY_TIER_PMEM 2
> > > > +
> > > > +#define MEMORY_RANK_HBM_GPU 300
> > > > +#define MEMORY_RANK_DRAM 200
> > > > +#define MEMORY_RANK_PMEM 100
> > > > +
> > > > +#define DEFAULT_MEMORY_TIER MEMORY_TIER_DRAM
> > > > +#define MAX_MEMORY_TIERS 3
> > > > +
> > > > +#endif /* CONFIG_TIERED_MEMORY */
> > > > +
> > > > +#endif
> > > > diff --git a/mm/Kconfig b/mm/Kconfig
> > > > index 169e64192e48..08a3d330740b 100644
> > > > --- a/mm/Kconfig
> > > > +++ b/mm/Kconfig
> > > > @@ -614,6 +614,17 @@ config ARCH_ENABLE_HUGEPAGE_MIGRATION
> > > > config ARCH_ENABLE_THP_MIGRATION
> > > > bool
> > > >
> > > > +config TIERED_MEMORY
> > > > + bool "Support for explicit memory tiers"
> > > > + def_bool n
> > > > + depends on MIGRATION && NUMA
> > > > + help
> > > > + Support to split nodes into memory tiers explicitly and
> > > > + to demote pages on reclaim to lower tiers. This option
> > > > + also exposes sysfs interface to read nodes available in
> > > > + specific tier and to move specific node among different
> > > > + possible tiers.
> > >
> > > IMHO we should not need a new kernel config. If tiering is not present
> > > then there is just one tier on the system. And tiering is a kind of
> > > hardware configuration, the information could be shown regardless of
> > > whether demotion/promotion is supported/enabled or not.
> >
> > I think so too. At least it appears unnecessary to let the user turn
> > on/off it at configuration time.
> >
> > All the code should be enclosed by #if defined(CONFIG_NUMA) &&
> > defined(CONIFIG_MIGRATION). So we will not waste memory in small
> > systems.
>
> CONFIG_NUMA alone should be good enough. CONFIG_MIGRATION is enabled
> by default if NUMA is enabled. And MIGRATION is just used to support
> demotion/promotion. Memory tiers exist even though demotion/promotion
> is not supported, right?
Yes. You are right. For example, in the following patch, memory tiers
are used for allocation interleaving.
https://lore.kernel.org/lkml/20220607171949.85796-1-hannes@cmpxchg.org/
Best Regards,
Huang, Ying
> >
> > > > +
> > > > config HUGETLB_PAGE_SIZE_VARIABLE
> > > > def_bool n
> > > > help
> > > > diff --git a/mm/Makefile b/mm/Makefile
> > > > index 6f9ffa968a1a..482557fbc9d1 100644
> > > > --- a/mm/Makefile
> > > > +++ b/mm/Makefile
> > > > @@ -92,6 +92,7 @@ obj-$(CONFIG_KFENCE) += kfence/
> > > > obj-$(CONFIG_FAILSLAB) += failslab.o
> > > > obj-$(CONFIG_MEMTEST) += memtest.o
> > > > obj-$(CONFIG_MIGRATION) += migrate.o
> > > > +obj-$(CONFIG_TIERED_MEMORY) += memory-tiers.o
> > > > obj-$(CONFIG_DEVICE_MIGRATION) += migrate_device.o
> > > > obj-$(CONFIG_TRANSPARENT_HUGEPAGE) += huge_memory.o khugepaged.o
> > > > obj-$(CONFIG_PAGE_COUNTER) += page_counter.o
> > > > diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> > > > new file mode 100644
> > > > index 000000000000..7de18d94a08d
> > > > --- /dev/null
> > > > +++ b/mm/memory-tiers.c
> > > > @@ -0,0 +1,188 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +#include <linux/types.h>
> > > > +#include <linux/device.h>
> > > > +#include <linux/nodemask.h>
> > > > +#include <linux/slab.h>
> > > > +#include <linux/memory-tiers.h>
> > > > +
> > > > +struct memory_tier {
> > > > + struct list_head list;
> > > > + struct device dev;
> > > > + nodemask_t nodelist;
> > > > + int rank;
> > > > +};
> > > > +
> > > > +#define to_memory_tier(device) container_of(device, struct memory_tier, dev)
> > > > +
> > > > +static struct bus_type memory_tier_subsys = {
> > > > + .name = "memtier",
> > > > + .dev_name = "memtier",
> > > > +};
> > > > +
> > > > +static DEFINE_MUTEX(memory_tier_lock);
> > > > +static LIST_HEAD(memory_tiers);
> > > > +
> > > > +
> > > > +static ssize_t nodelist_show(struct device *dev,
> > > > + struct device_attribute *attr, char *buf)
> > > > +{
> > > > + struct memory_tier *memtier = to_memory_tier(dev);
> > > > +
> > > > + return sysfs_emit(buf, "%*pbl\n",
> > > > + nodemask_pr_args(&memtier->nodelist));
> > > > +}
> > > > +static DEVICE_ATTR_RO(nodelist);
> > > > +
> > > > +static ssize_t rank_show(struct device *dev,
> > > > + struct device_attribute *attr, char *buf)
> > > > +{
> > > > + struct memory_tier *memtier = to_memory_tier(dev);
> > > > +
> > > > + return sysfs_emit(buf, "%d\n", memtier->rank);
> > > > +}
> > > > +static DEVICE_ATTR_RO(rank);
> > > > +
> > > > +static struct attribute *memory_tier_dev_attrs[] = {
> > > > + &dev_attr_nodelist.attr,
> > > > + &dev_attr_rank.attr,
> > > > + NULL
> > > > +};
> > > > +
> > > > +static const struct attribute_group memory_tier_dev_group = {
> > > > + .attrs = memory_tier_dev_attrs,
> > > > +};
> > > > +
> > > > +static const struct attribute_group *memory_tier_dev_groups[] = {
> > > > + &memory_tier_dev_group,
> > > > + NULL
> > > > +};
> > > > +
> > > > +static void memory_tier_device_release(struct device *dev)
> > > > +{
> > > > + struct memory_tier *tier = to_memory_tier(dev);
> > > > +
> > > > + kfree(tier);
> > > > +}
> > > > +
> > > > +/*
> > > > + * Keep it simple by having direct mapping between
> > > > + * tier index and rank value.
> > > > + */
> > > > +static inline int get_rank_from_tier(unsigned int tier)
> > > > +{
> > > > + switch (tier) {
> > > > + case MEMORY_TIER_HBM_GPU:
> > > > + return MEMORY_RANK_HBM_GPU;
> > > > + case MEMORY_TIER_DRAM:
> > > > + return MEMORY_RANK_DRAM;
> > > > + case MEMORY_TIER_PMEM:
> > > > + return MEMORY_RANK_PMEM;
> > > > + }
> > > > +
> > > > + return 0;
> > > > +}
> > > > +
> > > > +static void insert_memory_tier(struct memory_tier *memtier)
> > > > +{
> > > > + struct list_head *ent;
> > > > + struct memory_tier *tmp_memtier;
> > > > +
> > > > + list_for_each(ent, &memory_tiers) {
> > > > + tmp_memtier = list_entry(ent, struct memory_tier, list);
> > > > + if (tmp_memtier->rank < memtier->rank) {
> > > > + list_add_tail(&memtier->list, ent);
> > > > + return;
> > > > + }
> > > > + }
> > > > + list_add_tail(&memtier->list, &memory_tiers);
> > > > +}
> > > > +
> > > > +static struct memory_tier *register_memory_tier(unsigned int tier)
> > > > +{
> > > > + int error;
> > > > + struct memory_tier *memtier;
> > > > +
> > > > + if (tier >= MAX_MEMORY_TIERS)
> > > > + return NULL;
> > > > +
> > > > + memtier = kzalloc(sizeof(struct memory_tier), GFP_KERNEL);
> > > > + if (!memtier)
> > > > + return NULL;
> > > > +
> > > > + memtier->dev.id = tier;
> > > > + memtier->rank = get_rank_from_tier(tier);
> > > > + memtier->dev.bus = &memory_tier_subsys;
> > > > + memtier->dev.release = memory_tier_device_release;
> > > > + memtier->dev.groups = memory_tier_dev_groups;
> > > > +
> > > > + insert_memory_tier(memtier);
> > > > +
> > > > + error = device_register(&memtier->dev);
> > > > + if (error) {
> > > > + list_del(&memtier->list);
> > > > + put_device(&memtier->dev);
> > > > + return NULL;
> > > > + }
> > > > + return memtier;
> > > > +}
> > > > +
> > > > +__maybe_unused // temporay to prevent warnings during bisects
> > > > +static void unregister_memory_tier(struct memory_tier *memtier)
> > > > +{
> > > > + list_del(&memtier->list);
> > > > + device_unregister(&memtier->dev);
> > > > +}
> > > > +
> > > > +static ssize_t
> > > > +max_tier_show(struct device *dev, struct device_attribute *attr, char *buf)
> > > > +{
> > > > + return sysfs_emit(buf, "%d\n", MAX_MEMORY_TIERS);
> > > > +}
> > > > +static DEVICE_ATTR_RO(max_tier);
> > > > +
> > > > +static ssize_t
> > > > +default_tier_show(struct device *dev, struct device_attribute *attr, char *buf)
> > > > +{
> > > > + return sysfs_emit(buf, "memtier%d\n", DEFAULT_MEMORY_TIER);
> > > > +}
> > > > +static DEVICE_ATTR_RO(default_tier);
> > > > +
> > > > +static struct attribute *memory_tier_attrs[] = {
> > > > + &dev_attr_max_tier.attr,
> > > > + &dev_attr_default_tier.attr,
> > > > + NULL
> > > > +};
> > > > +
> > > > +static const struct attribute_group memory_tier_attr_group = {
> > > > + .attrs = memory_tier_attrs,
> > > > +};
> > > > +
> > > > +static const struct attribute_group *memory_tier_attr_groups[] = {
> > > > + &memory_tier_attr_group,
> > > > + NULL,
> > > > +};
> > > > +
> > > > +static int __init memory_tier_init(void)
> > > > +{
> > > > + int ret;
> > > > + struct memory_tier *memtier;
> > > > +
> > > > + ret = subsys_system_register(&memory_tier_subsys, memory_tier_attr_groups);
> > > > + if (ret)
> > > > + panic("%s() failed to register subsystem: %d\n", __func__, ret);
> > > > +
> > > > + /*
> > > > + * Register only default memory tier to hide all empty
> > > > + * memory tier from sysfs.
> > > > + */
> > > > + memtier = register_memory_tier(DEFAULT_MEMORY_TIER);
> > > > + if (!memtier)
> > > > + panic("%s() failed to register memory tier: %d\n", __func__, ret);
> > > > +
> > > > + /* CPU only nodes are not part of memory tiers. */
> > > > + memtier->nodelist = node_states[N_MEMORY];
> > > > +
> > > > + return 0;
> > > > +}
> > > > +subsys_initcall(memory_tier_init);
> > > > +
> > > > --
> > > > 2.36.1
> > > >
> >
> >
next prev parent reply other threads:[~2022-06-09 6:53 UTC|newest]
Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-03 13:42 [PATCH v5 0/9] mm/demotion: Memory tiers and demotion Aneesh Kumar K.V
2022-06-03 13:42 ` [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers Aneesh Kumar K.V
2022-06-07 18:43 ` Tim Chen
2022-06-07 20:18 ` Wei Xu
2022-06-08 4:30 ` Aneesh Kumar K V
2022-06-08 6:06 ` Ying Huang
2022-06-08 4:37 ` Aneesh Kumar K V
2022-06-08 6:10 ` Ying Huang
2022-06-08 8:04 ` Aneesh Kumar K V
2022-06-07 21:32 ` Yang Shi
2022-06-08 1:34 ` Ying Huang
2022-06-08 16:37 ` Yang Shi
2022-06-09 6:52 ` Ying Huang [this message]
2022-06-08 4:58 ` Aneesh Kumar K V
2022-06-08 6:18 ` Ying Huang
2022-06-08 16:42 ` Yang Shi
2022-06-09 8:17 ` Aneesh Kumar K V
2022-06-09 16:04 ` Yang Shi
2022-06-08 14:11 ` Johannes Weiner
2022-06-08 14:21 ` Aneesh Kumar K V
2022-06-08 15:55 ` Johannes Weiner
2022-06-08 16:13 ` Aneesh Kumar K V
2022-06-08 18:16 ` Johannes Weiner
2022-06-09 2:33 ` Aneesh Kumar K V
2022-06-09 13:55 ` Johannes Weiner
2022-06-09 14:22 ` Jonathan Cameron
2022-06-09 20:41 ` Johannes Weiner
2022-06-10 6:15 ` Ying Huang
2022-06-10 9:57 ` Jonathan Cameron
2022-06-13 14:05 ` Johannes Weiner
2022-06-13 14:23 ` Aneesh Kumar K V
2022-06-13 15:50 ` Johannes Weiner
2022-06-14 6:48 ` Ying Huang
2022-06-14 8:01 ` Aneesh Kumar K V
2022-06-14 18:56 ` Johannes Weiner
2022-06-15 6:23 ` Aneesh Kumar K V
2022-06-16 1:11 ` Ying Huang
2022-06-16 3:45 ` Wei Xu
2022-06-16 4:47 ` Aneesh Kumar K V
2022-06-16 5:51 ` Ying Huang
2022-06-17 10:41 ` Jonathan Cameron
2022-06-20 1:54 ` Huang, Ying
2022-06-14 16:45 ` Jonathan Cameron
2022-06-21 8:27 ` Aneesh Kumar K V
2022-06-03 13:42 ` [PATCH v5 2/9] mm/demotion: Expose per node memory tier to sysfs Aneesh Kumar K.V
2022-06-07 20:15 ` Tim Chen
2022-06-08 4:55 ` Aneesh Kumar K V
2022-06-08 6:42 ` Ying Huang
2022-06-08 16:06 ` Tim Chen
2022-06-08 16:15 ` Aneesh Kumar K V
2022-06-03 13:42 ` [PATCH v5 3/9] mm/demotion: Move memory demotion related code Aneesh Kumar K.V
2022-06-06 13:39 ` Bharata B Rao
2022-06-03 13:42 ` [PATCH v5 4/9] mm/demotion: Build demotion targets based on explicit memory tiers Aneesh Kumar K.V
2022-06-07 22:51 ` Tim Chen
2022-06-08 5:02 ` Aneesh Kumar K V
2022-06-08 6:52 ` Ying Huang
2022-06-08 6:50 ` Ying Huang
2022-06-08 8:19 ` Aneesh Kumar K V
2022-06-08 8:00 ` Ying Huang
2022-06-03 13:42 ` [PATCH v5 5/9] mm/demotion/dax/kmem: Set node's memory tier to MEMORY_TIER_PMEM Aneesh Kumar K.V
2022-06-03 13:42 ` [PATCH v5 6/9] mm/demotion: Add support for removing node from demotion memory tiers Aneesh Kumar K.V
2022-06-07 23:40 ` Tim Chen
2022-06-08 6:59 ` Ying Huang
2022-06-08 8:20 ` Aneesh Kumar K V
2022-06-08 8:23 ` Ying Huang
2022-06-08 8:29 ` Aneesh Kumar K V
2022-06-08 8:34 ` Ying Huang
2022-06-03 13:42 ` [PATCH v5 7/9] mm/demotion: Demote pages according to allocation fallback order Aneesh Kumar K.V
2022-06-03 13:42 ` [PATCH v5 8/9] mm/demotion: Add documentation for memory tiering Aneesh Kumar K.V
2022-06-03 13:42 ` [PATCH v5 9/9] mm/demotion: Update node_is_toptier to work with memory tiers Aneesh Kumar K.V
2022-06-06 3:11 ` Ying Huang
2022-06-06 3:52 ` Aneesh Kumar K V
2022-06-06 7:24 ` Ying Huang
2022-06-06 8:33 ` Aneesh Kumar K V
2022-06-08 7:26 ` Ying Huang
2022-06-08 8:28 ` Aneesh Kumar K V
2022-06-08 8:32 ` Ying Huang
2022-06-08 14:37 ` Aneesh Kumar K.V
2022-06-08 20:14 ` Tim Chen
2022-06-10 6:04 ` Ying Huang
2022-06-06 4:53 ` [PATCH] mm/demotion: Add sysfs ABI documentation Aneesh Kumar K.V
2022-06-08 13:57 ` [PATCH v5 0/9] mm/demotion: Memory tiers and demotion Johannes Weiner
2022-06-08 14:20 ` Aneesh Kumar K V
2022-06-09 8:53 ` Jonathan Cameron
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=287da19d187e816075e5772a22c63bdf9a5cb198.camel@intel.com \
--to=ying.huang@intel.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=apopple@nvidia.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=brice.goglin@gmail.com \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=feng.tang@intel.com \
--cc=gthelen@google.com \
--cc=hesham.almatary@huawei.com \
--cc=jvgediya@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=rientjes@google.com \
--cc=shy828301@gmail.com \
--cc=tim.c.chen@intel.com \
--cc=weixugc@google.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