On Thu, May 05, 2022 at 04:34:54PM +0200, Jan Beulich wrote: > On 05.05.2022 15:19, Roger Pau Monné wrote: > > On Mon, Apr 25, 2022 at 10:38:06AM +0200, Jan Beulich wrote: > >> No separate feature flags exist which would control availability of > >> these; the only restriction is HATS (establishing the maximum number of > >> page table levels in general), and even that has a lower bound of 4. > >> Thus we can unconditionally announce 2M, 1G, and 512G mappings. (Via > >> non-default page sizes the implementation in principle permits arbitrary > >> size mappings, but these require multiple identical leaf PTEs to be > >> written, which isn't all that different from having to write multiple > >> consecutive PTEs with increasing frame numbers. IMO that's therefore > >> beneficial only on hardware where suitable TLBs exist; I'm unaware of > >> such hardware.) > >> > >> Signed-off-by: Jan Beulich <jbeul...@suse.com> > > > > Reviewed-by: Roger Pau Monné <roger....@citrix.com> > > Thanks. > > >> --- > >> I'm not fully sure about allowing 512G mappings: The scheduling-for- > >> freeing of intermediate page tables would take quite a while when > >> replacing a tree of 4k mappings by a single 512G one. Yet then again > >> there's no present code path via which 512G chunks of memory could be > >> allocated (and hence mapped) anyway, so this would only benefit huge > >> systems where 512 1G mappings could be re-coalesced (once suitable code > >> is in place) into a single L4 entry. And re-coalescing wouldn't result > >> in scheduling-for-freeing of full trees of lower level pagetables. > > > > I would think part of this should go into the commit message, as to > > why enabling 512G superpages is fine. > > Together with what you say at the bottom I wonder whether, rather than > moving this into the description in a slightly edited form, I shouldn't > drop the PAGE_SIZE_512G there. I don't think that would invalidate your > R-b.
Right, might be good to add a comment that 512G super pages could be enabled (ie: there's no hardware limitation), but we need to be sure that the freeing of the removed page table pages doesn't starve the pCPU. Thanks, Roger.
