On 04/21/2018 12:07 AM, Marc Orr wrote: > First off---thanks for reviewing my patch! > > With respect to the size of the struct, here's what I'm seeing on an > upstream > version of the kernel: > > (gdb) p sizeof(struct kvm) > $1 = 42200 > (gdb) p sizeof(struct kvm_arch) > $2 = 35496 Yes, I looked at an older kernel on x86. Sorry about that. The newer kernels certainly have grown. Would be interesting to see why. Can you run pahole (usually in the package dwarves) on you kernel and search for "struct kvm " > > I'm pretty new to KVM--so it's not obvious to me: > - Why the size of this structure differs on my machine vs. yours > - What fields in 'struct kvm_arch' vary by architecture > > When I first read your email, my reaction was: > Let's vzalloc 'struct kvm' and kzalloc 'struct kvm_arch', but after looking > at > the size of 'struct kvm_arch' (see above), that obviously won't help :-). > > I'll add that my initial reaction when I was posed with this problem was > that > 40kB is NOTHING. But more experienced colleagues quickly explained to me > that > 40 kB is actually a lot for Linux to guarantee contiguously via kalloc. I'm > not > sure if the <13 kB that you're seeing in your environment is much better, > but > regardless, it seems like we're better off fixing this now rather than > dealing > with it later when the structure inevitably bloats, both in the upstream > kernel > and within people's domain-specific use cases. > > Thus, I wonder if folks have a suggestion on how to refactor these structs > so > that we can use valloc for most of the fields and partition > architecture-specific fields into a sub struct so that they can continue > being > allocated via kalloc. If we split this structure into multiple allocations then we might be able to continue to use kzalloc. pahole might show if there is a big datastructure in there that wants to be split out.
