[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87tugrxqks.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Fri, 05 Nov 2021 10:51:31 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Dave Hansen <dave.hansen@...el.com>,
Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc: <akpm@...ux-foundation.org>, <dave.hansen@...ux.intel.com>,
<ziy@...dia.com>, <osalvador@...e.de>, <shy828301@...il.com>,
<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] mm: migrate: Add new node demotion strategy
Dave Hansen <dave.hansen@...el.com> writes:
> On 11/4/21 2:13 AM, Baolin Wang wrote:
>> +What: /sys/kernel/mm/numa/demotion_mode
>> +Date: November 2021
>> +Contact: Linux memory management mailing list <linux-mm@...ck.org>
>> +Description: Set the demotion mode when enabling demoting pages during reclaim
>
> I don't think we need a tunable for this. The existing behavior is just
> stupid for your hardware and can be replaced.
Yes. I think so too. I don't think DIRECT_DEMOTION is reasonable for your system.
> Let's also try to do it with the existing node_demotion[] data
> structure before we go adding more.
To avoid cache ping-pong, I guess some kind of per-CPU data structure
may be more suitable for interleaving among multiple nodes.
Best Regards,
Huang, Ying
Powered by blists - more mailing lists