From: Yeoreum Yun <yeoreum.yun@arm.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: kernel test robot <oliver.sang@intel.com>,
Ryan Roberts <ryan.roberts@arm.com>,
oe-lkp@lists.linux.dev, lkp@intel.com,
Andrew Morton <akpm@linux-foundation.org>,
Muhammad Usama Anjum <usama.anjum@arm.com>,
Vlastimil Babka <vbabka@kernel.org>, Zi Yan <ziy@nvidia.com>,
Uladzislau Rezki <urezki@gmail.com>,
Brendan Jackman <jackmanb@google.com>,
David Sterba <dsterba@suse.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Liam Howlett <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>, Michal Hocko <mhocko@suse.com>,
Mike Rapoport <rppt@kernel.org>, Nick Terrell <terrelln@fb.com>,
Suren Baghdasaryan <surenb@google.com>,
Vishal Moola <vishal.moola@gmail.com>,
linux-mm@kvack.org
Subject: Re: [linux-next:master] [vmalloc] 60ced5818f: stress-ng.shm.ops_per_sec 7.2% regression
Date: Mon, 15 Jun 2026 17:45:49 +0100 [thread overview]
Message-ID: <ajAsPR661gzAuqLE@e129823.arm.com> (raw)
In-Reply-To: <87b8a714-e2bd-449d-9560-c181e927497a@kernel.org>
Hi David,
[...]
> Looking at the original results, I spotted
>
> 354997 ± 14% +111.6% 751255 ± 4% meminfo.PageTables
>
> So we consumed twice the (process) page tables. Did you also manage to reproduce
> that or do you have an explanation for that?
Unfortunately not, When I tried with the reproduce scripts and see the
peek usage of meminfo for Pagetable, it's almost the same (from 90000KB ~
100,000KB), I couldn't observe the this drasmatic usage increase via
this testcase. So I think this is not for this patch.
>
> >
> > Given that the regression appears to be driven by a synthetic workload that
> > combines frequent shmem page faults with repeated stack allocation/free operations,
> > I do not think this is a significant concern for typical real-world workloads.
>
> Yeah, if it's "we have less fragmentation", I agree. Using order-2 folios for
> shmem would likely similarly mitigate the problem I assume.
>
Agree. Thanks!
--
Sincerely,
Yeoreum Yun
prev parent reply other threads:[~2026-06-15 16:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-02 13:18 [linux-next:master] [vmalloc] 60ced5818f: stress-ng.shm.ops_per_sec 7.2% regression kernel test robot
2026-06-09 7:35 ` Yeoreum Yun
2026-06-15 9:51 ` Yeoreum Yun
2026-06-15 15:32 ` David Hildenbrand (Arm)
2026-06-15 16:45 ` Yeoreum Yun [this message]
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=ajAsPR661gzAuqLE@e129823.arm.com \
--to=yeoreum.yun@arm.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=dsterba@suse.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lkp@intel.com \
--cc=mhocko@suse.com \
--cc=oe-lkp@lists.linux.dev \
--cc=oliver.sang@intel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=terrelln@fb.com \
--cc=urezki@gmail.com \
--cc=usama.anjum@arm.com \
--cc=vbabka@kernel.org \
--cc=vishal.moola@gmail.com \
--cc=ziy@nvidia.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.