[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.23.453.2007011248580.1908531@chino.kir.corp.google.com>
Date: Wed, 1 Jul 2020 12:50:23 -0700 (PDT)
From: David Rientjes <rientjes@...gle.com>
To: Dave Hansen <dave.hansen@...el.com>
cc: "Huang, Ying" <ying.huang@...el.com>,
Yang Shi <yang.shi@...ux.alibaba.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kbusch@...nel.org, dan.j.williams@...el.com
Subject: Re: [RFC][PATCH 3/8] mm/vmscan: Attempt to migrate page in lieu of
discard
On Wed, 1 Jul 2020, Dave Hansen wrote:
> Even if they don't allocate directly from PMEM, is it OK for such an app
> to get its cold data migrated to PMEM? That's a much more subtle
> question and I suspect the kernel isn't going to have a single answer
> for it. I suspect we'll need a cpuset-level knob to turn auto-demotion
> on or off.
>
I think the answer is whether the app's cold data can be reclaimed,
otherwise migration to PMEM is likely better in terms of performance. So
any such app today should just be mlocking its cold data if it can't
handle overhead from reclaim?
Powered by blists - more mailing lists