lkml.org 
[lkml]   [2022]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Deprecating and removing SLOB
From
On 11/21/22 05:30, Damien Le Moal wrote:
> On 11/17/22 02:51, Vlastimil Babka wrote:
>> On 11/15/22 05:24, Damien Le Moal wrote:
>>> On 11/14/22 23:47, Hyeonggon Yoo wrote:
>>>> On Mon, Nov 14, 2022 at 08:35:31PM +0900, Damien Le Moal wrote:
>>>
>>> Test notes: I used Linus 6.1-rc5 as the base. That is the only thing I
>>> changed in buildroot default config for the sipeed maix bit card, booting
>>> with SD card. The test is: booting and run "cat /proc/vmstat" and register
>>> the nr_free_pages value. I repeated the boot + cat 3 to 4 times for each case.
>>>
>>> Here are the results:
>>>
>>> 6.1-rc5, SLOB:
>>> - 623 free pages
>>> - 629 free pages
>>> - 629 free pages
>>> 6.1-rc5, SLUB:
>>> - 448 free pages
>>> - 448 free pages
>>> - 429 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0:
>>> - Init error, shell prompt but no shell command working
>>> - Init error, no shell prompt
>>> - 508 free pages
>>> - Init error, shell prompt but no shell command working
>>> 6.1-rc5, SLUB + patch:
>>> - Init error, shell prompt but no shell command working
>>> - 433 free pages
>>> - 448 free pages
>>> - 423 free pages
>>> 6.1-rc5, SLUB + slub_max_order=0 + patch:
>>> - Init error, no shell prompt
>>> - Init error, shell prompt, 499 free pages
>>> - Init error, shell prompt but no shell command working
>>> - Init error, no shell prompt
>>>
>>> No changes for SLOB results, expected.
>>>
>>> For default SLUB, I did get all clean boots this time and could run the
>>> cat command. But I do see shell fork failures if I keep running commands.
>>>
>>> For SLUB + slub_max_order=0, I only got one clean boot with 508 free
>>> pages. Remaining runs failed to give a shell prompt or allow running cat
>>> command. For the clean boot, I do see higher number of free pages.
>>>
>>> SLUB with the patch was nearly identical to SLUB without the patch.
>>>
>>> And SLUB+patch+slub_max_order=0 gave again a lot of errors/bad boot. I
>>> could run the cat command only once, giving 499 free pages, so better than
>>> regular SLUB. But it seems that the memory is more fragmented as
>>> allocations fail more often.
>>>
>>> Hope this helps. Let me know if you want to test something else.
>>
>> Could you please try this branch with CONFIG_SLUB_TINY=y?
>> https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slub-tiny-v1r0
>>
>> Seeing your results I didn't modify default slub_max_order by this new
>> CONFIG (yet?) so maybe after trying the default, trying then also with
>> manual slub_max_order=0 and slub_max_order=1 would be useful too. Otherwise
>> it should be all changes to lower SLUB memory footprint. Hopefully it will
>> be visible in the number of free pages. But if fragmentation is an issue, it
>> might not be enough. BTW, during boot there should be a line "Built X
>> zonelists, mobility grouping ..." can you grep for it and provide please, I
>> wonder if mobility grouping ends up being off or on on that system.
>
> I ran your branch with CONFIG_SLUB_TINY=y. Here are the results with 3-4
> runs per config:
>
> * tiny slub with default slub_max_order:
> - Clean boot, 579 free pages
> - Clean boot, 575 free pages
> - Clean boot, 579 free pages
>
> * tiny slub with slub_max_order=0 as boot argument:
> - Init error, shell prompt but no shell command working
> - Init error, shell prompt, 592 free pages
> - Init error, shell prompt, 591 free pages
> - Init error, shell prompt, 591 free pages
>
> * tiny slub with slub_max_order=1 as boot argument:
> - Clean boot, 601 free pages
> - Clean boot, 601 free pages
> - Clean boot, 591 free pages
> - Clean boot, 601 free pages

Oh that's great result, better than I'd hope!
I'll change the default slub_max_order=1 with CONFIG_SLUB_TINY then.

> For all cases, mobility grouping was reported as off:
>
> [ 0.000000] Built 1 zonelists, mobility grouping off. Total pages: 2020

Yeah, expected that would be the case, thanks for confirming.

> So it looks like your tiny slub branch with slub_max_order=1 puts us
> almost on par with slob and that slub_max_order=0 seems to be generating
> more fragmentation leading to unreliable boot. I also tried
> slub_max_order=2, which gives clean boot and around 582 free pages, almost
> the same as the default.
>
> With this branch applied, I have no issues with having slob deprecated :)
> Thanks !

Great, thanks for the testing!

>>
>> Thanks!
>>
>>> Cheers.
>>>
>>
>

\
 
 \ /
  Last update: 2022-11-21 18:03    [W:1.773 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site