On Tue, 20 Mar 2018, Mikulas Patocka wrote: > > Maybe do the same thing for SLAB? > > Yes, but I need to change it for a specific cache, not for all caches. Why only some caches? > When the order is greater than 3 (PAGE_ALLOC_COSTLY_ORDER), the allocation > becomes unreliable, thus it is a bad idea to increase slub_max_order > system-wide. Well the allocations is more likely to fail that is true but SLUB will fall back to a smaller order should the page allocator refuse to give us that larger sized page. > Another problem with slub_max_order is that it would pad all caches to > slub_max_order, even those that already have a power-of-two size (in that > case, the padding is counterproductive). No it does not. Slub will calculate the configuration with the least byte wastage. It is not the standard order but the maximum order to be used. Power of two caches below PAGE_SIZE will have order 0. There are some corner cases where extra metadata is needed per object or per page that will result in either object sizes that are no longer a power of two or in page sizes smaller than the whole page. Maybe you have a case like that? Can you show me a cache that has this issue? > BTW. the function "order_store" in mm/slub.c modifies the structure > kmem_cache without taking any locks - is it a bug? The kmem_cache structure was just allocated. Only one thread can access it thus no locking is necessary. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
