On Mon, 26 Aug 2019, Vlastimil Babka wrote: > The topic has been discussed at LSF/MM 2019 [3]. Adding a 'kmalloc_aligned()' > variant would not help with code unknowingly relying on the implicit alignment. > For slab implementations it would either require creating more kmalloc caches, > or allocate a larger size and only give back part of it. That would be > wasteful, especially with a generic alignment parameter (in contrast with a > fixed alignment to size). The additional caches will be detected if similar to existing ones and merged into one. So the overhead is not that significant. > Ideally we should provide to mm users what they need without difficult > workarounds or own reimplementations, so let's make the kmalloc() alignment to > size explicitly guaranteed for power-of-two sizes under all configurations. The objection remains that this will create exceptions for the general notion that all kmalloc caches are aligned to KMALLOC_MINALIGN which may be suprising and it limits the optimizations that slab allocators may use for optimizing data use. The SLOB allocator was designed in such a way that data wastage is limited. The changes here sabotage that goal and show that future slab allocators may be similarly constrained with the exceptional alignents implemented. Additional debugging features etc etc must all support the exceptional alignment requirements. > * SLUB layout is also unchanged unless redzoning is enabled through > CONFIG_SLUB_DEBUG and boot parameter for the particular kmalloc cache. With > this patch, explicit alignment is guaranteed with redzoning as well. This > will result in more memory being wasted, but that should be acceptable in a > debugging scenario. Well ok. That sounds fine (apart from breaking the rules for slab object alignment). > * SLOB has no implicit alignment so this patch adds it explicitly for > kmalloc(). The potential downside is increased fragmentation. While > pathological allocation scenarios are certainly possible, in my testing, > after booting a x86_64 kernel+userspace with virtme, around 16MB memory > was consumed by slab pages both before and after the patch, with difference > in the noise. This change to slob will cause a significant additional use of memory. The advertised advantage of SLOB is that *minimal* memory will be used since it is targeted for embedded systems. Different types of slab objects of varying sizes can be allocated in the same memory page to reduce allocation overhead. Having these exceptional rules for aligning power of two sizes caches will significantly increase the memory wastage in SLOB. The result of this patch is just to use more memory to be safe from certain pathologies where one subsystem was relying on an alignment that was not specified. That is why this approach should not be called �natural" but "implicit alignment". The one using the slab cache is not aware that the slab allocator provides objects aligned in a special way (which is in general not needed. There seems to be a single pathological case that needs to be addressed and I thought that was due to some brokenness in the hardware?). It is better to ensure that subsystems that require special alignment explicitly tell the allocator about this. I still think implicit exceptions to alignments are a bad idea. Those need to be explicity specified and that is possible using kmem_cache_create().
