linux-kernel - Re: [RFC PATCH 0/4] Promotion of Unmapped Page Cache Folios.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20241127211803.87124-1-sj@kernel.org>
Date: Wed, 27 Nov 2024 13:18:03 -0800
From: SeongJae Park <sj@...nel.org>
To: Gregory Price <gourry@...rry.net>
Cc: SeongJae Park <sj@...nel.org>,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	nehagholkar@...a.com,
	abhishekd@...a.com,
	kernel-team@...a.com,
	david@...hat.com,
	ying.huang@...el.com,
	nphamcs@...il.com,
	akpm@...ux-foundation.org,
	hannes@...xchg.org,
	feng.tang@...el.com,
	kbusch@...a.com,
	damon@...ts.linux.dev
Subject: Re: [RFC PATCH 0/4] Promotion of Unmapped Page Cache Folios.

Hello,

On Wed, 27 Nov 2024 03:21:57 -0500 Gregory Price <gourry@...rry.net> wrote:

> Unmapped page cache pages can be demoted to low-tier memory, but
> they can presently only be promoted in two conditions:
>     1) The page is fully swapped out and re-faulted
>     2) The page becomes mapped (and exposed to NUMA hint faults)
> 
> This RFC proposes promoting unmapped page cache pages by using
> folio_mark_accessed as a hotness hint for unmapped pages.

Adding my thoughts that humble and biased as a DAMON maintainer.  The thoughts
are about the general problem, not about this patchset.  So please think below
as a sort of my "thinking loud" or "btw I use DAMON", and ignore those when
discussing about this specific patch series.

DAMON's access check mechanisms use PG_idle which is updated by
folio_mark_accessed(), and hence DAMON can monitor access to unmapped pages.
DAMON also supports migrating pages of specific access pattern to an arbitrary
NUMA node.  So, promoting unmapped page cache folios using DAMON might be
another way.

More specifically, users could use only DAMON for both promoting and demoting
of every page like HMSDK[1] does, or for only unmapped pages promotion.  I
think the former idea might work given previous test results, and I proposed an
idea[2] to make it more general (>2 tiers) and easy to tune using DAMOS quota
auto-tuning feature before.  All features for the proposed idea[2] are
available starting v6.11.   For the latter idea, though, I'm not sure how
beneficial it would be, and whether it makes sense at all.

For people who might be interested in it, or just how DAMON can be used for
such weird idea, I posted an RFC patch[3] for making DAMON be able to be used
for the use case.  For easy testing from anyone who interested, I also pushed
DAMON user-space tool's support of the new filter to a temporal branch[4].  The
temporal branch[4] might be erased later.

Note that I haven't test any of the two changes for the unmapped pages only
promotion idea, and have no ETA for any test.  Those are only for concept level
idea sharing.

[...]
> During development, we explored the following proposals:
[...]
> 4) Adding a separate kthread - suggested by many
> 
>    This is - to an extent - a more general version of the LRU proposal.
>    We still have to track the folios - which likely requires the
>    addition of a page flag.  Additionally, this method would actually
>    contend pretty heavily with LRU behavior - i.e. we'd want to
>    throttle addition to the promotion candidate list in some scenarios.

DAMON runs on a separate kthread, so DAMON-based approach maybe categorized
into this one.

[1] https://github.com/skhynix/hmsdk/wiki/Capacity-Expansion
[2] https://lore.kernel.org/damon/20231112195602.61525-1-sj@kernel.org/
[3] https://lore.kernel.org/20241127205624.86986-1-sj@kernel.org
[4] https://github.com/damonitor/damo/commit/32186d710355ef0dec55e3c6bd398fadeb9d136f

Thanks,
SJ

[...]