Re: [RFC PATCH v4] mm/slub: Optimize slub memory usage

[Vlastimil Babka <vbabka@suse.cz>]

On 8/10/23 19:54, Hyeonggon Yoo wrote:
>>                         order = calc_slab_order(size, min_objects,
>>                                         slub_max_order, fraction);
>> @@ -4159,14 +4164,6 @@ static inline int calculate_order(unsigned int size)
>>                 min_objects--;
>>         }
>> -       /*
>> -        * We were unable to place multiple objects in a slab. Now
>> -        * lets see if we can place a single object there.
>> -        */
>> -       order = calc_slab_order(size, 1, slub_max_order, 1);
>> -       if (order <= slub_max_order)
>> -               return order;
> 
> I'm not sure if it's okay to remove this?
> It was fine in v2 because the least wasteful order was chosen
> regardless of fraction but that's not true anymore.
> 
> Otherwise, everything looks fine to me. I'm too dumb to anticipate
> the outcome of increasing the slab order :P but this patch does not
> sound crazy to me.

I wanted to have a better idea how the orders change so I hacked up a patch
to print them for all sizes up to 1MB (unnecessarily large I guess) and also
for various page sizes and nr_cpus (that's however rather invasive and prone
to me missing some helper being used that still relies on real PAGE_SHIFT),
then I applied v4 (needed some conflict fixups with my hack) on top:

https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-orders

As expected, things didn't change with 4k PAGE_SIZE. With 64k PAGE_SIZE, I
thought the patch in v4 form would result in lower orders, but seems not always?

I.e. I can see before the patch:

 Calculated slab orders for page_shift 16 nr_cpus 1:
          8       0
       4376       1

(so until 4368 bytes it keeps order at 0)

And after:
          8       0
       2264       1
       2272       0
       2344       1
       2352       0
       2432       1

Not sure this kind of "oscillation" is helpful with a small machine (1CPU),
and 64kB pages so the unused part of page is quite small.

With 16 cpus, AFAICS the orders are also larger for some sizes.
Hm but you reported reduction of total slab memory which suggests lower
orders were selected somewhere, so maybe I did some mistake.

Anyway my point here is that this evaluation approach might be useful, even
if it's a non-upstreamable hack, and some postprocessing of the output is
needed for easier comparison of before/after, so feel free to try that out.

BTW I'll be away for 2 weeks from now, so further feedback will have to come
from others in that time...

> Thanks!
> --
> Hyeonggon