From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 224DCC4332F for ; Mon, 21 Nov 2022 17:02:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A3E836B0072; Mon, 21 Nov 2022 12:02:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9EF068E0001; Mon, 21 Nov 2022 12:02:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8B78C6B0074; Mon, 21 Nov 2022 12:02:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 7DD016B0072 for ; Mon, 21 Nov 2022 12:02:43 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 1DD231A07A4 for ; Mon, 21 Nov 2022 17:02:43 +0000 (UTC) X-FDA: 80158068606.19.626F46A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf17.hostedemail.com (Postfix) with ESMTP id 21BF640015 for ; Mon, 21 Nov 2022 17:02:41 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 74C2B220D3; Mon, 21 Nov 2022 17:02:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1669050160; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=waH8qi7rSOq7I4vWunq+Hx7MA0/6o23u8Uhy7medoKs=; b=M3t81rO8cMELjgUY3Pdvd3u12xeF18kly28iM45Jh2xBoA0q2rqwb0X1LTQJ7XKitDOpmg C7kIz1ftFw/3KzsErpk7pinZ8z5Ecv924W6QC4bxFzdhwCNayzo79WGuPIOHQ5GuHtijlT cZfAnna+18wBK9/wokB1Iwkp2Ft+kzg= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1669050160; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=waH8qi7rSOq7I4vWunq+Hx7MA0/6o23u8Uhy7medoKs=; b=tyZD79BhpWMMOi79km59eEyhlhrTkn1DIB8dMHZeEyXRwr6a+tN9XlBAvcIgXaWLoiX7dC n3OtrqDkpmh6CiAg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E13501377F; Mon, 21 Nov 2022 17:02:39 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id Slg/Ni+ve2OJdAAAMHmgww (envelope-from ); Mon, 21 Nov 2022 17:02:39 +0000 Message-ID: Date: Mon, 21 Nov 2022 18:02:39 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: Deprecating and removing SLOB Content-Language: en-US To: Damien Le Moal , Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Conor Dooley , Pasha Tatashin , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Matthew Wilcox , Roman Gushchin , Linus Torvalds , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Catalin Marinas , Rustam Kovhaev , Andrew Morton , Josh Triplett , Arnd Bergmann , Russell King , Alexander Shiyan , Aaro Koskinen , Janusz Krzysztofik , Tony Lindgren , Yoshinori Sato , Rich Felker , Jonas Bonn , Stefan Kristiansson , Stafford Horne , "linux-arm-kernel@lists.infradead.org" , openrisc@lists.librecores.org, linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, Geert Uytterhoeven , Conor.Dooley@microchip.com, Paul Cercueil References: <93079aba-362e-5d1e-e9b4-dfe3a84da750@opensource.wdc.com> <44da078c-b630-a249-bf50-67df83cd8347@suse.cz> <35650fd4-3152-56db-7c27-b9997e31cfc7@opensource.wdc.com> <97c0735c-3127-83d5-30ff-8e57c6634f6e@opensource.wdc.com> <452c3833-9275-37c7-3d48-5c996c0e2557@suse.cz> <6a1883c4-4c3f-545a-90e8-2cd805bcf4ae@opensource.wdc.com> From: Vlastimil Babka In-Reply-To: <6a1883c4-4c3f-545a-90e8-2cd805bcf4ae@opensource.wdc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669050162; a=rsa-sha256; cv=none; b=0D5mTf+jf+jGSIKyCwhL2M+76BMeDTXiSBSis3Py1bntddK3qG1yLlWmi+J7ycTvofAdP6 cj4Ive9sf0hJp3iNhTN6qe2lnR/o81Nlx8cP/tmQMWXZz/Jd81GHmYhMYsWRlwNCZeiQYV H6W6HW55pktYgLj8F8Xp/qW9hmFkg+w= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=M3t81rO8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=tyZD79Bh; dmarc=none; spf=pass (imf17.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669050162; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=waH8qi7rSOq7I4vWunq+Hx7MA0/6o23u8Uhy7medoKs=; b=vexhAXH+wPEfNsivSMmxrATxRjLJQxenncv7iO7q0UrhJJlgQQxbiOX+uaUDXrnrV+A+Ej 34m/ZfQKSsZXsLS2lspK6hS8nucdKB0c5Vehb+HbDAgEHbz4KV5QJyJKISAeA7zmMju2pa +naumwZWIVteBBCvALWyGre70fVTe1s= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 21BF640015 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=M3t81rO8; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=tyZD79Bh; dmarc=none; spf=pass (imf17.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Stat-Signature: 97b57zcgs5qjkjczx7sgju8iyhznhe8u X-HE-Tag: 1669050161-275624 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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. >>> >> >