On Mon, Oct 29, 2018 at 9:48 AM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > On Mon, Oct 29, 2018 at 09:25:05AM -0700, Jim Mattson wrote: > > On Sun, Oct 28, 2018 at 6:58 PM, Wanpeng Li <kernellwp@xxxxxxxxx> wrote: > > > We have not yet encounter memory is too fragmented to allocate kvm > > > related metadata in our overcommit pools, is this true requirement > > > from the product environments? > > > > Yes. > > Are your logs granular enough to determine if turning this into an > order-2 allocation (by splitting out "struct fpu" allocations) will be > sufficient to resolve your problem, or do we need to turn it into an > order-1 or vmalloc allocation to achieve your production goals? As noted in my response to Dave Hansen, I've got his suggestions done and they were successful in drastically reducing the size of the vcpu_vmx struct, which is great. Specifically, on an upstream kernel, I've reduced the size of the struct from 23680 down to 15168, which is order 2. All that being said, I don't really understand why we wouldn't convert this memory allocation from a kmalloc() into a vmalloc(). From my point of view, we are still close to bloating vcpu_vmx into an order 3 allocation, and it's common for vendors to append to both vcpu_vmx directly, or more likely to its embedded structs. Though, arguably, vendors should not be doing that. Most importantly, it just isn't obvious to me why kmalloc() is preferred over vmalloc(). From my point of view, vmalloc() does the exact same thing as kmalloc(), except that it works when contiguous memory is sparse, which seems better to me.
