[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87v9j6k7lw.fsf@yhuang-dev.intel.com>
Date: Thu, 02 Jul 2020 09:50:51 +0800
From: "Huang\, Ying" <ying.huang@...el.com>
To: David Rientjes <rientjes@...gle.com>
Cc: Dave Hansen <dave.hansen@...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
David Rientjes <rientjes@...gle.com> writes:
> 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?
Yes. That's a way to solve the problem. A cpuset-level knob may be
more flexible, because you don't need to change the application source
code.
Best Regards,
Huang, Ying
Powered by blists - more mailing lists