From: "Huang, Ying" <ying.huang@linux.alibaba.com>
To: Gregory Price <gourry@gourry.net>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
nehagholkar@meta.com, abhishekd@meta.com, kernel-team@meta.com,
david@redhat.com, nphamcs@gmail.com, akpm@linux-foundation.org,
hannes@cmpxchg.org, kbusch@meta.com
Subject: Re: [RFC v2 PATCH 0/5] Promotion of Unmapped Page Cache Folios.
Date: Fri, 27 Dec 2024 10:16:42 +0800 [thread overview]
Message-ID: <87v7v5g99x.fsf@DESKTOP-5N7EMDA> (raw)
In-Reply-To: <Z2g8xuCgqoqbpmtZ@gourry-fedora-PF4VCD3F> (Gregory Price's message of "Sun, 22 Dec 2024 11:22:30 -0500")
Gregory Price <gourry@gourry.net> writes:
> On Sun, Dec 22, 2024 at 03:09:44PM +0800, Huang, Ying wrote:
>> Gregory Price <gourry@gourry.net> writes:
>> > That's 3-6% performance in this contrived case.
>>
>> This is small too.
>>
>
> Small is relative. 3-6% performance increase across millions of servers
> across a year is a non trivial speedup for such a common operation.
If we cannot only get 3-6% performance increase in a micro-benchmark,
how much can we get from a real life workloads?
Anyway, we need to prove the usefulness of the change via data. 3-6%
isn't some strong data.
Can we measure the largest improvement? For example, run the benchmark
with all file pages in DRAM and CXL.mem via numa binding, and compare.
>> > Can easily piggyback on that, just wasn't sure if overloading it was
>> > an acceptable idea.
>>
>> It's the recommended setup in the original PMEM promotion
>> implementation. Please check commit c959924b0dc5 ("memory tiering:
>> adjust hot threshold automatically").
>>
>> > Although since that promotion rate limit is also
>> > per-task (as far as I know, will need to read into it a bit more) this
>> > is probably fine.
>>
>> It's not per-task. Please read the code, especially
>> should_numa_migrate_memory().
>
> Oh, then this is already throttled. We call mpol_misplaced which calls
> should_numa_migrate_memory.
>
> There's some duplication of candidate selection logic between
> promotion_candidate and should_numa_migrate_memory, but it may be
> beneficial to keep it that way. I'll have to look.
---
Best Regards,
Huang, Ying
next prev parent reply other threads:[~2024-12-27 2:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-10 21:37 [RFC v2 PATCH 0/5] Promotion of Unmapped Page Cache Folios Gregory Price
2024-12-10 21:37 ` [RFC v2 PATCH 1/5] migrate: Allow migrate_misplaced_folio_prepare() to accept a NULL VMA Gregory Price
2024-12-10 21:37 ` [RFC v2 PATCH 2/5] memory: move conditionally defined enums use inside ifdef tags Gregory Price
2024-12-27 10:34 ` Donet Tom
2024-12-27 15:42 ` Gregory Price
2024-12-29 14:49 ` Donet Tom
2024-12-10 21:37 ` [RFC v2 PATCH 3/5] memory: allow non-fault migration in numa_migrate_check path Gregory Price
2024-12-10 21:37 ` [RFC v2 PATCH 4/5] vmstat: add page-cache numa hints Gregory Price
2024-12-27 10:48 ` Donet Tom
2024-12-27 15:49 ` Gregory Price
2024-12-29 14:57 ` Donet Tom
2025-01-03 10:18 ` Donet Tom
2025-01-03 19:19 ` Gregory Price
2024-12-10 21:37 ` [RFC v2 PATCH 5/5] migrate,sysfs: add pagecache promotion Gregory Price
2024-12-27 11:01 ` Donet Tom
2024-12-27 15:56 ` Gregory Price
2024-12-29 15:00 ` Donet Tom
2024-12-21 5:18 ` [RFC v2 PATCH 0/5] Promotion of Unmapped Page Cache Folios Huang, Ying
2024-12-21 14:48 ` Gregory Price
2024-12-22 7:09 ` Huang, Ying
2024-12-22 16:22 ` Gregory Price
2024-12-27 2:16 ` Huang, Ying [this message]
2024-12-27 15:40 ` Gregory Price
2024-12-27 19:09 ` Gregory Price
2024-12-28 3:38 ` Gregory Price
2024-12-31 7:32 ` Gregory Price
2025-01-02 2:58 ` Huang, Ying
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=87v7v5g99x.fsf@DESKTOP-5N7EMDA \
--to=ying.huang@linux.alibaba.com \
--cc=abhishekd@meta.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=kbusch@meta.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nehagholkar@meta.com \
--cc=nphamcs@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.