[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8182ede7-88ce-b891-d100-8c036130797e@intel.com>
Date: Wed, 1 Jul 2020 11:20:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: "Huang, Ying" <ying.huang@...el.com>,
David Rientjes <rientjes@...gle.com>
Cc: 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 7/1/20 1:54 AM, Huang, Ying wrote:
> Why can not we just bind the memory of the application to node 0, 2, 3
> via mbind() or cpuset.mems? Then the application can allocate memory
> directly from PMEM. And if we bind the memory of the application via
> mbind() to node 0, we can only allocate memory directly from DRAM.
Applications use cpuset.mems precisely because they don't want to
allocate directly from PMEM. They want the good, deterministic,
performance they get from DRAM.
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.
Powered by blists - more mailing lists