Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard

[Dave Hansen]

On 10/16/19 8:45 PM, Shakeel Butt wrote:
> On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx> wrote:
>> This set implements a solution to these problems.  At the end of the
>> reclaim process in shrink_page_list() just before the last page
>> refcount is dropped, the page is migrated to persistent memory instead
>> of being dropped.
..> The memory cgroup part of the story is missing here. Since PMEM is
> treated as slow DRAM, shouldn't its usage be accounted to the
> corresponding memcg's memory/memsw counters and the migration should
> not happen for memcg limit reclaim? Otherwise some jobs can hog the
> whole PMEM.

My expectation (and I haven't confirmed this) is that the any memory use
is accounted to the owning cgroup, whether it is DRAM or PMEM.  memcg
limit reclaim and global reclaim both end up doing migrations and
neither should have a net effect on the counters.

There is certainly a problem here because DRAM is a more valuable
resource vs. PMEM, and memcg accounts for them as if they were equally
valuable.  I really want to see memcg account for this cost discrepancy
at some point, but I'm not quite sure what form it would take.  Any
feedback from you heavy memcg users out there would be much appreciated.

> Also what happens when PMEM is full? Can the memory migrated to PMEM
> be reclaimed (or discarded)?

Yep.  The "migration path" can be as long as you want, but once the data
hits a "terminal node" it will stop getting migrated and normal discard
at the end of reclaim happens.