[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87ikvefswp.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Mon, 02 Sep 2024 14:53:26 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Gregory Price <gourry@...rry.net>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
akpm@...ux-foundation.org, david@...hat.com, nphamcs@...il.com,
nehagholkar@...a.com, abhishekd@...a.com, Johannes Weiner
<hannes@...xchg.org>, Feng Tang <feng.tang@...el.com>
Subject: Re: [PATCH 0/3] mm,TPP: Enable promotion of unmapped pagecache
Gregory Price <gourry@...rry.net> writes:
> On Mon, Aug 19, 2024 at 03:46:00PM +0800, Huang, Ying wrote:
>> Gregory Price <gourry@...rry.net> writes:
>>
>> > Unmapped pagecache pages can be demoted to low-tier memory, but
>> > they can only be promoted if a process maps the pages into the
>> > memory space (so that NUMA hint faults can be caught). This can
>> > cause significant performance degradation as the pagecache ages
>> > and unmapped, cached files are accessed.
>> >
>> > This patch series enables the pagecache to request a promotion of
>> > a folio when it is accessed via the pagecache.
>> >
>> > We add a new `numa_hint_page_cache` counter in vmstat to capture
>> > information on when these migrations occur.
>>
>> It appears that you will promote page cache page on the second access.
>> Do you have some better way to identify hot pages from the not-so-hot
>> pages? How to balance between unmapped and mapped pages? We have hot
>> page selection for hot pages.
>>
>> [snip]
>>
>
> I've since explored moving this down under a (referenced && active) check.
>
> This would be more like promotion on third access within an LRU shrink
> round (the LRU should, in theory, hack off the active bits on some decent
> time interval when the system is pressured).
>
> Barring adding new counters to folios to track hits, I don't see a clear
> and obvious way way to track hotness. The primary observation here is
> that pagecache is un-mapped, and so cannot use numa-fault hints.
>
> This is more complicated with MGLRU, but I'm saving that for after I
> figure out the plan for plain old LRU.
Several years ago, we have tried to use the access time tracking
mechanism of NUMA balancing to track the access time latency of unmapped
file cache folios. The original implementation is as follows,
https://git.kernel.org/pub/scm/linux/kernel/git/vishal/tiering.git/commit/?h=tiering-0.8&id=5f2e64ce75c0322602c2ec8c70b64bb69b1f1329
What do you think about this?
--
Best Regards,
Huang, Ying
Powered by blists - more mailing lists