On Wed, Oct 31, 2018 at 01:17:40PM +0000, Marc Orr wrote: > 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. It's ever-so-slightly faster to access kmalloc memory than vmalloc memory; kmalloc memory comes from the main kernel mapping, generally mapped with 1GB pages while vmalloc memory is necessarily accessed using 4kB pages, taking an extra two steps in the page table hierarchy. There's more software overhead involved too; in addition to allocating the physical pages (which both kmalloc and vmalloc have to do), vmalloc has to allocate a vmap_area and a vm_struct to describe the virtual mapping. The virtual address space can also get fragmented, just like the physical address space does, potentially leading to the amusing scenario where you can allocate physically contiguous memory, but not find a contiguous chunk of vmalloc space to put it in. For larger allocations, we tend to prefer kvmalloc() which gives us the best of both worlds, allocating from kmalloc first and vmalloc as a fallback, but you've got some fun gyrations to go through to do physical mapping, so that's not entirely appropriate for your case.
