linux-kernel - Re: [RFC] mm/swap.c: Enable promotion of unmapped MGLRU page cache pages

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: <Z4fd0WP7MxhHjQKn@gourry-fedora-PF4VCD3F>
Date: Wed, 15 Jan 2025 11:09:53 -0500
From: Gregory Price <gourry@...rry.net>
To: Donet Tom <donettom@...ux.ibm.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, Yu Zhao <yuzhao@...gle.com>,
	Ritesh Harjani <ritesh.list@...il.com>,
	"Aneesh Kumar K . V" <aneesh.kumar@...nel.org>,
	Matthew Wilcox <willy@...radead.org>,
	David Hildenbrand <david@...hat.com>,
	Huang Ying <ying.huang@...ux.alibaba.com>,
	Johannes Weiner <hannes@...xchg.org>
Subject: Re: [RFC] mm/swap.c: Enable promotion of unmapped MGLRU page cache
 pages

On Wed, Jan 15, 2025 at 06:06:25AM -0600, Donet Tom wrote:
... snip ...

Thank you for taking the time to do this, I don't have enough background
with MGLRU to have done this quickly.  I'll pull this onto my branch and
carry it if you don't mind so we can keep things tracked.

I'll send you an updated RFC before i send out v4 and add appropriate tags.

> This difference also impacts read latency:
> 
> For MGLRU, the first read shows higher latency due to the combined
> overhead of accessing a lower tier and performing promotion.
> 
> For LRU, the first 3–4 reads typically exhibit lower latency since
> promotion does not occur immediately.
>

Do you have a thought on a good test we can use to compare these
strategies?

We decided against promotion on first-access because there are many
easy-to-imagine scenarios where that will clearly harm performance.

We're planning to do some workload testing soon so we can get actual
benefit numbers.

> +promo_candid:
> +	if (!folio_test_isolated(folio) &&
> +		(sysctl_numa_balancing_mode & NUMA_BALANCING_MEMORY_TIERING) &&
> +		numa_pagecache_promotion_enabled) {

I am considering putting this in some inline wrapper with some likely()
tags to clean this up a bit and optimize the fall-through cases since
i've seen some measurable differences when left as-is.

Thoughts on this are welcome

> +		memcg = folio_memcg(folio);
> +		if (memcg) {

Also curious, why only promote when the folio is a member of a memcg?

~Gregory