linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Huang, Ying" <ying.huang@linux.alibaba.com>
To: Zhu Haoran <zhr1502@sjtu.edu.cn>
Cc: linux-mm@kvack.org
Subject: Re: [Question] About memory.c: process_huge_page
Date: Thu, 25 Sep 2025 09:32:58 +0800	[thread overview]
Message-ID: <87y0q3e2ph.fsf@DESKTOP-5N7EMDA> (raw)
In-Reply-To: <20250924114619.2532-1-zhr1502@sjtu.edu.cn> (Zhu Haoran's message of "Wed, 24 Sep 2025 19:46:03 +0800")

Hi, Haoran,

Zhu Haoran <zhr1502@sjtu.edu.cn> writes:

> Hi!
>
> I recently noticed the process_huge_page function in memory.c, which was
> intended to keep the cache hotness of target page after processing. I compared
> the vm-scalability anon-cow-seq-hugetlb microbench using the default
> process_huge_page and sequential processing (code posted below).
>
> I ran test on epyc-7T83 with 36vCPUs and 64GB memory. Using default
> process_huge_page, the avg bandwidth is 1148 mb/s. However sequential
> processing yielded a better bandwidth of about 1255 mb/s and only
> one-third cache-miss rate compared with default one.
>
> The same test was run on epyc-9654 with 36vCPU and 64GB mem. The
> bandwidth result was similar but the difference was smaller: 1170mb/s
> for default and 1230 mb/s for sequential. Although we did find the cache
> miss rate here did the reverse, since the sequential processing seen 3
> times miss more than the default.
>
> These result seem really inconsitent with the what described in your
> patchset [1]. What factors might explain these behaviors?

One possible difference is cache topology.  Can you try to bind the test
process to the CPUs in one CCX (that is, share one LLC).  This make it
possible to hit the local cache.

> Thanks for your time.
>
> [1] https://lkml.org/lkml/2018/5/23/1072
>
> ---
> Sincere,
> Zhu Haoran
>
> ---
>
> static int process_huge_page(
>         unsigned long addr_hint, unsigned int nr_pages,
>         int (*process_subpage)(unsigned long addr, int idx, void *arg),
>         void *arg)
> {
>     int i, ret;
>     unsigned long addr = addr_hint &
>         ~(((unsigned long)nr_pages << PAGE_SHIFT) - 1);
>
>     might_sleep();
>     for (i = 0; i < nr_pages; i++) {
>             cond_resched();
>             ret = process_subpage(addr + i * PAGE_SIZE, i, arg);
>             if (ret)
>                     return ret;
>     }
>
>     return 0;
> }

---
Best Regards,
Huang, Ying


  reply	other threads:[~2025-09-25  1:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-24 11:46 Zhu Haoran
2025-09-25  1:32 ` Huang, Ying [this message]
2025-09-25  3:38   ` Dev Jain
2025-09-26 12:40     ` Zhu Haoran
2025-09-26 12:27   ` Zhu Haoran
2025-09-28  0:48     ` Huang, Ying
2025-09-28 10:07       ` Zhu Haoran
2025-10-09  1:23         ` Huang, Ying
2025-09-26 12:38   ` Zhu Haoran

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=87y0q3e2ph.fsf@DESKTOP-5N7EMDA \
    --to=ying.huang@linux.alibaba.com \
    --cc=linux-mm@kvack.org \
    --cc=zhr1502@sjtu.edu.cn \
    /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