Re: [RFC PATCH 0/8] mm/memcontrol: introduce per-tier memory accounting and control

From: Qiqi Liu <[email protected]>

Hi all,

Thank you all for your replies. I am not very familiar with the
community's workflow and should have reviewed the mailing list
archives and existing implementations more carefully. I sincerely
apologize for any inconvenience this may have caused.

My work is based on
https://lore.kernel.org/all/[email protected]/
aiming to develop memory tiering limits for cgroups. During
development, I referenced Joshua's v2, but failed to notice that
v3 had already been posted when I submitted my series.

I have studied Joshua's v3, and our core mechanisms are largely
consistent. However, there are two differences:

1. Read/write per-tier interface (memory.tier): each cgroup
   tracks its memory usage by tier (e.g., DRAM, CXL), exposed
   via a new memory.tier control file. This file reports
   per-tier usage and accepts per-tier high (soft limit) and
   max (hard limit) settings. By default, these limits are
   automatically derived from memory.high/max based on each
   tier's capacity ratio, but manual overrides are supported,
   allowing administrators to constrain specific tiers on a
   per-cgroup basis.

   Its advantages are:
   - It can express allocations that fixed capacity ratios
     cannot.
   - Latency-sensitive tenants can be given a larger share of
     the fast tier.
   - High-capacity tenants can have their soft limits removed
     for the slow tier.

   Whether or not to constrain a specific tier should be a
   decision made by the administrator on a per-cgroup basis.
   This serves as an answer to Michal's earlier question in
   the thread regarding "do you intend to limit memory
   consumption on particular tier even without an external
   pressure?"

2. Per-tier stock: I have implemented and tested per-tier
   stock -- it batches atomic operations on tier counters from
   per-page to every 32 pages. Joshua's patch (moving the stock
   down to the page_counter level) takes a more generic
   approach, and I believe we should continue with his
   direction here.

Memory hardware is becoming increasingly diverse (DRAM, CXL,
and further remote tiers), and the performance gaps between
tiers are significant. Different workloads have different
requirements -- some demand low latency, while others need
capacity. When the fast tier cannot accommodate the working
sets of all workloads, it should be the administrator's
scheduling decision to determine fast-tier allocations. I
believe tier-aware control is a direction worth pursuing, and
the differences above are where we can contribute.

As Shakeel suggested, and given that Joshua's v3 already
contains the core mechanism, I am dropping my current
standalone patchset. I would like to ask if Joshua would be
willing to collaborate with me on this, treating memory.tier
as an extension to the patch series and proposing it as
follow-up patches based on v3.

PS: I have already subscribed to the mailing list to avoid
such misunderstandings in the future.

Best regards,
Qiqi Liu