On Fri, 20 Apr 2018, Marc Orr wrote: > 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. The issue is that this generates an order-4 allocation which results in significant fragmentation, is unmovable, and has an unexpected life cycle. This very often requires memory compaction to free up an otherwise movable pageblock since not many MIGRATE_UNMOVABLE pageblocks have order-4 memory free. That makes the target pageblock also MIGRATE_UNMOVALBE because this is a GFP_KERNEL allocation and we can't migrate it. The struct would be *much* more fragmentation friendly if it were order-0 or order-1 because we often have one or two pages available from existing MIGRATE_UNMOVABLE pageblocks. The ultimate goal is to free as many full pageblocks as possible for transparent hugepages. > 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. > Is it possible for someone to enumerate what exactly in struct kvm absolutely needs to be contiguous? It seems like there is a concern about struct kvm_arch and whether the requirements differ depending on the platform. Are there others? Worst case scenario is that each arch has its own kvm_arch allocator that does kzalloc, vzalloc, or a combination depending on its requirements.
