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. > > "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. > -Mike -- Sincerely yours, Mike.
