On Mon, 23 Apr 2018, David Matlack wrote:
> > Seems to be
> > struct hlist_head mmu_page_hash[4096]; /* 24 32768 */
>
> > in kvm_arch.
>
> > This is now much larger mostly due to
>
> > commit 114df303a7eeae8b50ebf68229b7e647714a9bea
> > kvm: x86: reduce collisions in mmu_page_hash
>
>
> > So maybe it is enough to allocate mmu_page_hash seperately? Adding David
> Matlack
> > for opinions.
>
> Allocating mmu_page_hash separately would not create any issues I can think
> of. But Mark's concern about future bloat still remains.
>
> One option to move forward would be to make this change x86-specific by
> overriding kvm_arch_{alloc,free}_vm. Other architectures could do the same
> once they check that it's safe.
>
x86 already appears to be doing that in kvm_x86_ops, but struct kvm_arch
still is embedded into struct kvm. I'm wondering if there are any issues
with dynamically allocating kvm_arch for all architectures and then having
a per-arch override for how to allocate struct kvm_arch (kzalloc or
vzalloc or something else) depending on its needs?
