include/linux/memcontrol.h | 1 + include/linux/memory-tiers.h | 2 + mm/memcontrol.c | 86 +++++++++++++++++++++++++++++++++++- mm/memory-tiers.c | 3 +- 4 files changed, 89 insertions(+), 3 deletions(-)
For controlling usage of a top tiered memory by a cgroup, accounting of top tier memory usage is needed. This patch set implements the following: Patch 1 introduces interface and simple implementation to retrieve cgroup tiered memory usage Patch 2 introduces more efficient accounting with top tier memory page counter Patch 3 provides a sysfs interface to repot the the top tiered memory usage. The patchset works with Aneesh's v6 memory-tiering implementation [1]. It is a preparatory patch set before introducing features to control top tiered memory in cgroups. I'll like to first get feedback to see if (1) Controllng the topmost tiered memory is enough or (2) Multiple tiers at the top levels need to be grouped into "toptier" or (3) There are use cases not covered by (1) and (2). Thanks. Tim [1] https://lore.kernel.org/linux-mm/20220610135229.182859-1-aneesh.kumar@linux.ibm.com/ Tim Chen (3): mm/memory-tiers Add functions for tier memory usage in a cgroup mm/memory-tiers: Use page counter to track toptier memory usage mm/memory-tiers: Show toptier memory usage for cgroup include/linux/memcontrol.h | 1 + include/linux/memory-tiers.h | 2 + mm/memcontrol.c | 86 +++++++++++++++++++++++++++++++++++- mm/memory-tiers.c | 3 +- 4 files changed, 89 insertions(+), 3 deletions(-) -- 2.35.1
On Tue 14-06-22 15:25:32, Tim Chen wrote: > For controlling usage of a top tiered memory by a cgroup, accounting > of top tier memory usage is needed. This patch set implements the > following: > > Patch 1 introduces interface and simple implementation to retrieve > cgroup tiered memory usage > Patch 2 introduces more efficient accounting with top tier memory page counter > Patch 3 provides a sysfs interface to repot the the top tiered memory > usage. I guess you meant cgroupfs here, right? > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > It is a preparatory patch set before introducing features to > control top tiered memory in cgroups. > > I'll like to first get feedback to see if > (1) Controllng the topmost tiered memory is enough > or > (2) Multiple tiers at the top levels need to be grouped into "toptier" > or > (3) There are use cases not covered by (1) and (2). I would start by asking why do we need a dedicated interface in the first place. Why the existing numa_stat is not a proper interface. Right now we only report LRU per node stats. Is this insufficient? What is userspace expect to do based on the reported data? -- Michal Hocko SUSE Labs
On Wed, 2022-06-15 at 13:11 +0200, Michal Hocko wrote: > On Tue 14-06-22 15:25:32, Tim Chen wrote: > > For controlling usage of a top tiered memory by a cgroup, accounting > > of top tier memory usage is needed. This patch set implements the > > following: > > > > Patch 1 introduces interface and simple implementation to retrieve > > cgroup tiered memory usage > > Patch 2 introduces more efficient accounting with top tier memory page counter > > Patch 3 provides a sysfs interface to repot the the top tiered memory > > usage. > > I guess you meant cgroupfs here, right? Yes. > > > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > > It is a preparatory patch set before introducing features to > > control top tiered memory in cgroups. > > > > I'll like to first get feedback to see if > > (1) Controllng the topmost tiered memory is enough > > or > > (2) Multiple tiers at the top levels need to be grouped into "toptier" > > or > > (3) There are use cases not covered by (1) and (2). > > I would start by asking why do we need a dedicated interface in the > first place. Why the existing numa_stat is not a proper interface. Right > now we only report LRU per node stats. Is this insufficient? > What is userspace expect to do based on the reported data? Exporting the toptier information here is convenient for me for debugging purpose of seeing whether a cgroup's toptier usage is under control. Otherwise writing a script to parse numastat and the memtier heirachy will work too. Exporting toptier usage directly is optional and we don't have to do it. Tim
On Wed 15-06-22 08:23:56, Tim Chen wrote: > On Wed, 2022-06-15 at 13:11 +0200, Michal Hocko wrote: [...] > > > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > > > It is a preparatory patch set before introducing features to > > > control top tiered memory in cgroups. > > > > > > I'll like to first get feedback to see if > > > (1) Controllng the topmost tiered memory is enough > > > or > > > (2) Multiple tiers at the top levels need to be grouped into "toptier" > > > or > > > (3) There are use cases not covered by (1) and (2). > > > > I would start by asking why do we need a dedicated interface in the > > first place. Why the existing numa_stat is not a proper interface. Right > > now we only report LRU per node stats. Is this insufficient? > > What is userspace expect to do based on the reported data? > > Exporting the toptier information here is convenient for me for debugging > purpose of seeing whether a cgroup's toptier usage is under control. > Otherwise writing a script to parse numastat and the memtier heirachy will > work too. Exporting toptier usage directly is optional and we don't have to do it. Please keep in mind this is an userspace API which has to be maintained for ever. We do not add those just to make debugging more convenient. -- Michal Hocko SUSE Labs
On Tue, 2022-06-14 at 15:25 -0700, Tim Chen wrote: > For controlling usage of a top tiered memory by a cgroup, accounting > of top tier memory usage is needed. This patch set implements the > following: > > Patch 1 introduces interface and simple implementation to retrieve > cgroup tiered memory usage > Patch 2 introduces more efficient accounting with top tier memory page counter > Patch 3 provides a sysfs interface to repot the the top tiered memory > usage. > > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > It is a preparatory patch set before introducing features to > control top tiered memory in cgroups. > > I'll like to first get feedback to see if > (1) Controllng the topmost tiered memory is enough > or > (2) Multiple tiers at the top levels need to be grouped into "toptier" > or If we combine top-N tiers, I think the better name could be "fast-tier", in contrast to "slow-tier". > (3) There are use cases not covered by (1) and (2). Is it necessary to control memory usage of each tier (except the lowest/slowest)? I am not the right person to answer the question, but I want to ask it. Best Regards, Huang, Ying > Thanks. > > Tim > > [1] https://lore.kernel.org/linux-mm/20220610135229.182859-1-aneesh.kumar@linux.ibm.com/ > > Tim Chen (3): > mm/memory-tiers Add functions for tier memory usage in a cgroup > mm/memory-tiers: Use page counter to track toptier memory usage > mm/memory-tiers: Show toptier memory usage for cgroup > > include/linux/memcontrol.h | 1 + > include/linux/memory-tiers.h | 2 + > mm/memcontrol.c | 86 +++++++++++++++++++++++++++++++++++- > mm/memory-tiers.c | 3 +- > 4 files changed, 89 insertions(+), 3 deletions(-) >
On Wed, 2022-06-15 at 12:58 +0800, Ying Huang wrote: > On Tue, 2022-06-14 at 15:25 -0700, Tim Chen wrote: > > For controlling usage of a top tiered memory by a cgroup, accounting > > of top tier memory usage is needed. This patch set implements the > > following: > > > > Patch 1 introduces interface and simple implementation to retrieve > > cgroup tiered memory usage > > Patch 2 introduces more efficient accounting with top tier memory page counter > > Patch 3 provides a sysfs interface to repot the the top tiered memory > > usage. > > > > The patchset works with Aneesh's v6 memory-tiering implementation [1]. > > It is a preparatory patch set before introducing features to > > control top tiered memory in cgroups. > > > > I'll like to first get feedback to see if > > (1) Controllng the topmost tiered memory is enough > > or > > (2) Multiple tiers at the top levels need to be grouped into "toptier" > > or > > If we combine top-N tiers, I think the better name could be "fast-tier", > in contrast to "slow-tier". > I can see use cases for grouping tiers. For example, it makese sense for HBM and DRAM tiers be grouped together into a "fast-tier-group". To make things simple, we can define any tiers above or equal to the rank of DRAM will belong to this fast-tier-group. An implication for page promotion/demotion is it needs to take tier grouping into consideration. You want to demote pages away from current tier-group. For example, you want to demote HBM (fast-tier-group) into PMEM (slow-tier-group) instead of into DRAM (fast-tier-group). The question is whether fast/slow tier groups are sufficient. Or you need fast/slow/slower groups? > > (3) There are use cases not covered by (1) and (2). > > Is it necessary to control memory usage of each tier (except the > lowest/slowest)? I am not the right person to answer the question, but > I want to ask it. > I have the same question. Tim
© 2016 - 2026 Red Hat, Inc.