[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CA+KHdyUgK6hSbrKMpH1YqtadzBDFR=SnBUY-hCHnzkLqmcPf6A@mail.gmail.com>
Date: Thu, 18 Dec 2025 18:37:30 +0100
From: Uladzislau Rezki <urezki@...il.com>
To: Oliver Sang <oliver.sang@...el.com>
Cc: oe-lkp@...ts.linux.dev, lkp@...el.com, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>, Michal Hocko <mhocko@...e.com>, Baoquan He <bhe@...hat.com>,
Alexander Potapenko <glider@...gle.com>, Andrey Ryabinin <ryabinin.a.a@...il.com>,
Marco Elver <elver@...gle.com>, Michal Hocko <mhocko@...nel.org>, linux-mm@...ck.org
Subject: Re: [linus:master] [mm/vmalloc] 9c47753167: stress-ng.bigheap.realloc_calls_per_sec
21.3% regression
Hello, Oliver.
No, thank you!
As i mentioned i do not see how pointed patches can affect performance.
--
Uladzislsua Rezki
On Thu, Dec 18, 2025 at 5:38 AM Oliver Sang <oliver.sang@...el.com> wrote:
>
> hi, Uladzislau Rezki,
>
> On Wed, Dec 17, 2025 at 12:04:20PM +0100, Uladzislau Rezki wrote:
> > Hello, Oliver.
> >
> > > > >
> > > > > Hello,
> > > > >
> > > > > kernel test robot noticed a 21.3% regression of stress-ng.bigheap.realloc_calls_per_sec on:
> > > > >
> > > > >
> > > > > commit: 9c47753167a6a585d0305663c6912f042e131c2d ("mm/vmalloc: defer freeing partly initialized vm_struct")
> > > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > > >
> > > > > [still regression on linus/master c9b47175e9131118e6f221cc8fb81397d62e7c91]
> > > > > [still regression on linux-next/master 008d3547aae5bc86fac3eda317489169c3fda112]
> > > > >
> > > > > testcase: stress-ng
> > > > > config: x86_64-rhel-9.4
> > > > > compiler: gcc-14
> > > > > test machine: 256 threads 2 sockets Intel(R) Xeon(R) 6767P CPU @ 2.4GHz (Granite Rapids) with 256G memory
> > > > > parameters:
> > > > >
> > > > > nr_threads: 100%
> > > > > testtime: 60s
> > > > > test: bigheap
> > > > > cpufreq_governor: performance
> > > > >
> > > > >
> > > > >
> > > > > If you fix the issue in a separate patch/commit (i.e. not just a new version of
> > > > > the same patch/commit), kindly add following tags
> > > > > | Reported-by: kernel test robot <oliver.sang@...el.com>
> > > > > | Closes: https://lore.kernel.org/oe-lkp/202512121138.986f6a6b-lkp@intel.com
> > > > >
> > > > >
> > >
> > > [...]
> > >
> > > > >
> > > > Could you please test below patch and confirm if it solves regression:
> > >
> > > we directly apply the patch upon 9c47753167, so our test branch looks like below
> > >
> > > * f7991e8a0136cb <---- below patch from you
> > > * 9c47753167a6a5 mm/vmalloc: defer freeing partly initialized vm_struct
> > > * 86e968d8ca6dc8 mm/vmalloc: support non-blocking GFP flags in alloc_vmap_area()
> > >
> > > but found it has little performance impacts
> > >
> > > =========================================================================================
> > > compiler/cpufreq_governor/kconfig/nr_threads/rootfs/tbox_group/test/testcase/testtime:
> > > gcc-14/performance/x86_64-rhel-9.4/100%/debian-13-x86_64-20250902.cgz/lkp-gnr-2sp3/bigheap/stress-ng/60s
> > >
> > > 86e968d8ca6dc823 9c47753167a6a585d0305663c69 f7991e8a0136cb0fdf35f11e28a
> > > ---------------- --------------------------- ---------------------------
> > > %stddev %change %stddev %change %stddev
> > > \ | \ | \
> > > 48320196 -10.9% 43072080 -10.8% 43116499 stress-ng.bigheap.ops
> > > 785159 -9.8% 708390 -9.7% 708644 stress-ng.bigheap.ops_per_sec
> > > 879805 -21.3% 692805 -20.7% 697312 stress-ng.bigheap.realloc_calls_per_sec
> > >
> > Thank you for testing. I had same expectations. No difference.
> > Honestly i can not figure out how:
> >
> > * 9c47753167a6a5 mm/vmalloc: defer freeing partly initialized vm_struct
> > * 86e968d8ca6dc8 mm/vmalloc: support non-blocking GFP flags in alloc_vmap_area()
> >
> > can effect performance. I am not doing anything related to performance.
> > I would like to ask you if you could test one more thing. I see that
> >
> > [still regression on linus/master c9b47175e9131118e6f221cc8fb81397d62e7c91]
> >
> > contains also below patch:
> >
> > <snip>
> > commit a0615780439938e8e61343f1f92a4c54a71dc6a5
> > mm/vmalloc: request large order pages from buddy allocator
> > <snip>
> >
> > where we try to use larger order for vmalloc. Could you please revert
> > it and rerun same tests?
> >
> > Thank you in advance!
>
> we've seen comments from Mateusz Guzik in
> https://lore.kernel.org/all/e4b6sjeh22uqhxhxudsbanlnyo2potwowuy7mkrp6tvxnftjn4@mcjyes2s3eu6/
> that this could be related with cacheline bouncing.
>
> not sure if you still want us to do the test you mentioned?
>
> if so, sorry that I cannot make a clean covert of a061578043993 on
> c9b47175e9131. could you prepare a patch for us? thanks
>
>
>
> >
> > --
> > Uladzislau Rezki
--
Uladzislau Rezki
Powered by blists - more mailing lists