On Thu, Feb 16, 2023 at 10:07 AM Ricardo Koller <ricarkol@xxxxxxxxxx> wrote:
>
> On Wed, Feb 15, 2023 at 4:36 PM Oliver Upton <oliver.upton@xxxxxxxxx> wrote:
> >
> > On Wed, Feb 15, 2023 at 05:40:38PM +0000, Ricardo Koller wrote:
> >
> > [...]
> >
> > > diff --git a/arch/arm64/kvm/hyp/pgtable.c b/arch/arm64/kvm/hyp/pgtable.c
> > > index fed314f2b320..e2fb78398b3d 100644
> > > --- a/arch/arm64/kvm/hyp/pgtable.c
> > > +++ b/arch/arm64/kvm/hyp/pgtable.c
> > > @@ -1229,6 +1229,111 @@ int kvm_pgtable_stage2_create_unlinked(struct kvm_pgtable *pgt,
> > > return 0;
> > > }
> > >
> > > +struct stage2_split_data {
> > > + struct kvm_s2_mmu *mmu;
> > > + void *memcache;
> > > + u64 mc_capacity;
> > > +};
> > > +
> > > +/*
> > > + * Get the number of page-tables needed to replace a bock with a fully
> > > + * populated tree, up to the PTE level, at particular level.
> > > + */
> > > +static inline u32 stage2_block_get_nr_page_tables(u32 level)
> > > +{
> > > + switch (level) {
> > > + /* There are no blocks at level 0 */
> > > + case 1: return 1 + PTRS_PER_PTE;
> > > + case 2: return 1;
> > > + case 3: return 0;
> > > + default:
> > > + WARN_ON_ONCE(1);
> > > + return ~0;
> > > + }
> > > +}
> >
> > This doesn't take into account our varying degrees of hugepage support
> > across page sizes. Perhaps:
> >
> > static inline int stage2_block_get_nr_page_tables(u32 level)
> > {
> > if (WARN_ON_ONCE(level < KVM_PGTABLE_MIN_BLOCK_LEVEL ||
> > level >= KVM_PGTABLE_MAX_LEVELS))
> > return -EINVAL;
> >
> > switch (level) {
> > case 1:
> > return PTRS_PER_PTE + 1;
> > case 2:
> > return 1;
> > case 3:
> > return 0;
> > }
> > }
> >
> > paired with an explicit error check and early return on the caller side.
>
> Sounds good, will add this to the next version.
>
> >
> > > +static int stage2_split_walker(const struct kvm_pgtable_visit_ctx *ctx,
> > > + enum kvm_pgtable_walk_flags visit)
> > > +{
> > > + struct kvm_pgtable_mm_ops *mm_ops = ctx->mm_ops;
> > > + struct stage2_split_data *data = ctx->arg;
> > > + kvm_pte_t pte = ctx->old, new, *childp;
> > > + enum kvm_pgtable_prot prot;
> > > + void *mc = data->memcache;
> > > + u32 level = ctx->level;
> > > + u64 phys, nr_pages;
> > > + bool force_pte;
> > > + int ret;
> > > +
> > > + /* No huge-pages exist at the last level */
> > > + if (level == KVM_PGTABLE_MAX_LEVELS - 1)
> > > + return 0;
> > > +
> > > + /* We only split valid block mappings */
> > > + if (!kvm_pte_valid(pte))
> > > + return 0;
> > > +
> > > + nr_pages = stage2_block_get_nr_page_tables(level);
> > > + if (data->mc_capacity >= nr_pages) {
> > > + /* Build a tree mapped down to the PTE granularity. */
> > > + force_pte = true;
> > > + } else {
> > > + /*
> > > + * Don't force PTEs. This requires a single page of PMDs at the
> > > + * PUD level, or a single page of PTEs at the PMD level. If we
> > > + * are at the PUD level, the PTEs will be created recursively.
> > > + */
> > > + force_pte = false;
> > > + nr_pages = 1;
> > > + }
> >
> > Do we know if the 'else' branch here is even desirable? I.e. has
> > recursive shattering been tested with PUD hugepages (HugeTLB 1G) and
> > shown to improve guest performance while dirty tracking?
>
> Yes, I think it's desirable. Here are some numbers on a neoverse n1 using
> dirty_log_perf_test (152 vcpus, 1G each, 4K pages):
>
> CHUNK_SIZE=1G
> Enabling dirty logging time: 2.468014046s
> Iteration 1 dirty memory time: 4.275447900s
>
> CHUNK_SIZE=2M
> Enabling dirty logging time: 2.692124099s
> Iteration 1 dirty memory time: 4.284682220s
>
> Enabling dirty logging increases as expected when using a smaller CHUNK_SIZE,
> but not by too much (~9%). It's a fair tradeoff for users not willing
> to allocate large
> caches.
>
> >
> > The observations we've made on existing systems were that the successive
> > break-before-make operations led to a measurable slowdown in guest
> > pre-copy performance. Recursively building the page tables should
> > actually result in *more* break-before-makes than if we just let the vCPU
> > fault path lazily shatter hugepages.
> >
> > --
> > Thanks,
> > Oliver
There is a terribly offensive image that was attached to the previous
email. I would like to apologize for
attaching it. I don't know how that happened.
Ricardo
