Hello, On Wed, 27 Nov 2024 03:21:57 -0500 Gregory Price <gourry@xxxxxxxxxx> 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@xxxxxxxxxx/ [3] https://lore.kernel.org/20241127205624.86986-1-sj@xxxxxxxxxx [4] https://github.com/damonitor/damo/commit/32186d710355ef0dec55e3c6bd398fadeb9d136f Thanks, SJ [...]
