On Fri, Oct 26, 2018 at 05:29:48AM -0700, Matthew Wilcox wrote: > A question that may have been asked already, but if so I didn't see it ... > does kvm_vcpu need to be so damn big? It's 22kB with the random .config > I happen to have (which gets rounded to 32kB, an order-3 allocation). If > we can knock 6kB off it (either by allocating pieces separately), it becomes > an order-2 allocation. So, biggest chunks: > > struct kvm_vcpu_arch arch; /* 576 21568 */ > > struct kvm_mmu mmu; /* 336 400 */ > struct kvm_mmu nested_mmu; /* 736 400 */ > struct fpu user_fpu; /* 2176 4160 */ > struct fpu guest_fpu; /* 6336 4160 */ > struct kvm_cpuid_entry2 cpuid_entries[80]; /* 10580 3200 */ > struct x86_emulate_ctxt emulate_ctxt; /* 13792 2656 */ > struct kvm_pmu pmu; /* 17344 1520 */ > struct kvm_vcpu_hv hyperv; /* 18872 1872 */ > gfn_t gfns[64]; /* 20832 512 */ > > that's about 19kB of the 22kB right there. Can any of them be shrunk > in size or allocated separately? I just had a fun conversation with Dave Hansen (cc'd) in which he indicated that the fpu should definitely be dynamically allocated. See also his commits from 2015 around XSAVE. 0c8c0f03e3a292e031596484275c14cf39c0ab7a 4109ca066b6b899ac7549bf3aac94b178ac95891