On Tue, Jan 16, 2024 at 10:12:26PM +0200, Mike Rapoport wrote: > On Tue, Jan 16, 2024 at 10:50:25AM -0600, Michael Roth wrote: > > On Tue, Jan 16, 2024 at 10:19:09AM -0600, Michael Roth wrote: > > > > > > The downside of course is potential impact for non-SNP workloads > > > resulting from splitting the directmap. Mike Rapoport's numbers make > > > me feel a little better about it, but I don't think they apply directly > > > to the notion of splitting the entire directmap. It's Even he LWN article > > > summarizes: > > When I ran the tests, I had the entire direct map forced to 4k or 2M pages. > There is indeed some impact and some tests suffer more than others but > there were also runs that benefit from smaller page size in the direct map, > at least if I remember correctly the results Intel folks posted a while > ago. I see, thanks for clarifying. Certainly helps to have this data if someone ends up wanting to investigate pre-splitting directmap to optimize SNP use-cases in the future. Still feel more comfortable introducing this as an optional tuneable though; can't help but worry about that *1* workload that somehow suffers perf regression and has us frantically re-working SNP implementation if we were to start off with making 4k directmap a requirement. > > > > "The conclusion from all of this, Rapoport continued, was that > > > direct-map fragmentation just does not matter — for data access, at > > > least. Using huge-page mappings does still appear to make a difference > > > for memory containing the kernel code, so allocator changes should > > > focus on code allocations — improving the layout of allocations for > > > loadable modules, for example, or allowing vmalloc() to allocate huge > > > pages for code. But, for kernel-data allocations, direct-map > > > fragmentation simply appears to not be worth worrying about." > > > > > > So at the very least, if we went down this path, we would be worth > > > investigating the following areas in addition to general perf testing: > > > > > > 1) Only splitting directmap regions corresponding to kernel-allocatable > > > *data* (hopefully that's even feasible...) > > Forcing the direct map to 4k pages does not affect the kernel text > mappings, they are created separately and they are not the part of the > kernel mapping of the physical memory. > Well, except the modules, but they are mapped with 4k pages anyway. Thanks! -Mike > > > -Mike > > -- > Sincerely yours, > Mike.
