On 04/23/2018 09:48 PM, David Rientjes wrote:
> 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.
That would certainly work. On the other hand it would be good if we could keep
as much code as possible common across architectures.
Paolo, Radim, any preference?
>>
>
> 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?
The disadvantage of allocation vs embedding is that this is one additional pointer
chase for code that could be cache cold (e.g. guest was running). I have absolutely
no idea if that matters at all or not.
