Messages in this thread | | | Date | Mon, 3 Jul 2023 11:38:59 -0700 | From | Kees Cook <> | Subject | Re: [PATCH v2] mm/slub: disable slab merging in the default configuration |
| |
On Mon, Jul 03, 2023 at 12:33:25PM +0200, Julian Pidancet wrote: > On Mon Jul 3, 2023 at 02:09, David Rientjes wrote: > > I think we need more data beyond just kernbench. Christoph's point about > > different page sizes is interesting. In the above results, I don't know > > the page orders for the various slab caches that this workload will > > stress. I think the memory overhead data may be different depending on > > how slab_max_order is being used, if at all. > > > > We should be able to run this through a variety of different benchmarks > > and measure peak slab usage at the same time for due diligence. I support > > the change in the default, I would just prefer to know what the > > implications of it is. > > > > Is it possible to collect data for other microbenchmarks and real-world > > workloads? And perhaps also with different page sizes where this will > > impact memory overhead more? I can help running more workloads once we > > have the next set of data. > > > > David, > > I agree about the need to perform those tests on hardware using larger > pages. I will collect data if I have the chance to get my hands on one > of these systems. > > Do you have specific tests or workload in mind ? Compiling the kernel > with files sitting on an XFS partition is not exhaustive but it is the > only test I could think of that is both easy to set up and can be > reproduced while keeping external interferences as little as possible.
I think it is a sufficiently complicated heap allocation workload (and real-world). I'd prefer we get this change landed in -next after -rc1 so we can see if there are any regressions reported by the 0day and other CI performance tests.
-Kees
-- Kees Cook
| |