Re: [PATCH v1 11/26] x86/sev: Invalidate pages from the direct map when adding them to the RMP table

Michael Roth
2024-01-26T01:59:19Z

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.