From: Gregory Price <gourry@gourry.net>
To: Donet Tom <donettom@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Yu Zhao <yuzhao@google.com>,
Ritesh Harjani <ritesh.list@gmail.com>,
"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
David Hildenbrand <david@redhat.com>,
Huang Ying <ying.huang@linux.alibaba.com>,
Johannes Weiner <hannes@cmpxchg.org>
Subject: Re: [RFC] mm/swap.c: Enable promotion of unmapped MGLRU page cache pages
Date: Wed, 15 Jan 2025 11:09:53 -0500 [thread overview]
Message-ID: <Z4fd0WP7MxhHjQKn@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <20250115120625.3785-1-donettom@linux.ibm.com>
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
next prev parent reply other threads:[~2025-01-15 16:09 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 12:06 Donet Tom
2025-01-15 13:25 ` Matthew Wilcox
2025-01-16 11:10 ` Donet Tom
2025-01-16 18:46 ` Matthew Wilcox
2025-01-15 16:09 ` Gregory Price [this message]
2025-01-16 11:16 ` Donet Tom
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z4fd0WP7MxhHjQKn@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=david@redhat.com \
--cc=donettom@linux.ibm.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ritesh.list@gmail.com \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.com \
--cc=yuzhao@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox