linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Shakeel Butt <shakeelb@google.com>
To: Dave Hansen <dave.hansen@intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	 Linux MM <linux-mm@kvack.org>,
	Dan Williams <dan.j.williams@intel.com>,
	 Jonathan Adams <jwadams@google.com>,
	"Chen, Tim C" <tim.c.chen@intel.com>
Subject: Re: [PATCH 0/4] [RFC] Migrate Pages in lieu of discard
Date: Thu, 17 Oct 2019 09:58:01 -0700	[thread overview]
Message-ID: <CALvZod7kqjPJcdNQu3CO0+GU=0PyUE1YZgrDJcs8dBHpKbLkSg@mail.gmail.com> (raw)
In-Reply-To: <496566a6-2581-17f4-a4f2-e5def7f97582@intel.com>

On Thu, Oct 17, 2019 at 7:26 AM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 10/16/19 8:45 PM, Shakeel Butt wrote:
> > On Wed, Oct 16, 2019 at 3:49 PM Dave Hansen <dave.hansen@linux.intel.com> 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.
>

Hmm I didn't see the memcg charge migration in the code on demotion.
So, in the code [patch 3] the counters are being decremented as DRAM
is freed but not incremented for PMEM.

> 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.
>

There are two apparent use-cases i.e. explicit (apps moving their
pages to PMEM to reduce cost) and implicit (admin moves cold pages to
PMEM transparently to the apps) for the PMEM. In the implicit case, I
see both DRAM and PMEM as same resource from the perspective of memcg
limits i.e. same memcg counter, something like cgroup v1's  memsw).
For the explicit case, maybe separate counters make sense like cgroup
v2's memory and swap.

> > 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.

I might have missed it but I didn't see the migrated pages inserted
back to LRUs. If they are not in LRU, the reclaimer will never see
them.


  reply	other threads:[~2019-10-17 16:58 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-16 22:11 Dave Hansen
2019-10-16 22:11 ` [PATCH 1/4] node: Define and export memory migration path Dave Hansen
2019-10-17 11:12   ` Kirill A. Shutemov
2019-10-17 11:44     ` Kirill A. Shutemov
2019-10-16 22:11 ` [PATCH 2/4] mm/migrate: Defer allocating new page until needed Dave Hansen
2019-10-17 11:27   ` Kirill A. Shutemov
2019-10-16 22:11 ` [PATCH 3/4] mm/vmscan: Attempt to migrate page in lieu of discard Dave Hansen
2019-10-17 17:30   ` Yang Shi
2019-10-18 18:15     ` Dave Hansen
2019-10-18 21:02       ` Yang Shi
2019-10-16 22:11 ` [PATCH 4/4] mm/vmscan: Consider anonymous pages without swap Dave Hansen
2019-10-17  3:45 ` [PATCH 0/4] [RFC] Migrate Pages in lieu of discard Shakeel Butt
2019-10-17 14:26   ` Dave Hansen
2019-10-17 16:58     ` Shakeel Butt [this message]
2019-10-17 20:51       ` Dave Hansen
2019-10-17 17:20     ` Yang Shi
2019-10-17 21:05       ` Dave Hansen
2019-10-17 22:58       ` Shakeel Butt
2019-10-18 21:44         ` Yang Shi
2019-10-17 16:01 ` Suleiman Souhlal
2019-10-17 16:32   ` Dave Hansen
2019-10-17 16:39     ` Shakeel Butt
2019-10-18  8:11     ` Suleiman Souhlal
2019-10-18 15:10       ` Dave Hansen
2019-10-18 15:39         ` Suleiman Souhlal
2019-10-18  7:44 ` Michal Hocko
2019-10-18 14:54   ` Dave Hansen
2019-10-18 21:39     ` Yang Shi
2019-10-18 21:55       ` Dan Williams
2019-10-22 13:49     ` Michal Hocko

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='CALvZod7kqjPJcdNQu3CO0+GU=0PyUE1YZgrDJcs8dBHpKbLkSg@mail.gmail.com' \
    --to=shakeelb@google.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jwadams@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=tim.c.chen@intel.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