On Mon, Feb 13, 2023 at 11:33 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote: > > Hi Gavin, > > On Tue, Feb 14, 2023 at 04:57:59PM +1100, Gavin Shan wrote: > > On 2/7/23 3:58 AM, Ricardo Koller wrote: > > <snip> > > > > Eager Page Splitting fixes the above two issues by eagerly splitting > > > huge-pages when enabling dirty logging. The goal is to avoid doing it > > > while faulting on write-protected pages. > > </snip> > > > I'm not sure why we can't eagerly split the PMD mapping into 512 PTE > > mapping in the page fault handler? > > The entire goal of the series is to avoid page splitting at all on the > stage-2 abort path. Ideally we want to minimize the time taken to handle > a fault so we can get back to running the guest. The requirement to > perform a break-before-make operation to change the mapping granularity > can, as Ricardo points out, be a bottleneck on contemporary implementations. > > There is a clear uplift with the proposed implementation already, and I > would expect that margin to widen if/when we add support for lockless > (i.e. RCU-protected) permission relaxation. There's also the issue of allocating 513 pages on fault when splitting PUDs. > > > In the implementation, the newly introduced API > > kvm_pgtable_stage2_split() calls to kvm_pgtable_stage2_create_unlinked() > > and then stage2_map_walker(), which is part of kvm_pgtable_stage2_map(), > > to create the unlinked page tables. > > This is deliberate code reuse. Page table construction in the fault path > is largely similar to that of eager split besides the fact that one is > working on 'live' page tables whereas the other is not. As such I gave > the suggestion to Ricardo to reuse what we have today for the sake of > eager splitting. > > -- > Thanks, > Oliver
