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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4C173C4332F for ; Wed, 16 Nov 2022 07:59:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=Pcvv1FL3j+ENbMsfNJKMoqmedmH4Pk9Ugou2ZclmcPA=; b=pDxHl9Q4A6iSxF EYEOSK/imxJBJNiqnijlot26wZIDviTYBdrRyHXU5QvMfBXk0aZU5eY5M2fOeq8stltfDyG/2RzxP HpoZKLHtuG/k9fPGRdMgivUZM2J4BDWtKKO5Ezc3wIDXx1J4I/S4Cfn1VfC8JDM8EocuGaxlxEcc1 LtWnsxwCuThxphLKg/vN24qgORHjlqTS36yawlbUKg6BPa2hnctbNLu1AZzMKd4HxdH3PWCAZ7GHQ aK+kpYQL2WVKl2CHgU4Hhj6j516vmBWu53o43glD+QQKN15yQRMbZxeDKha+Xn4cz9UkDT8gmz91q gef4kiHuMLiv0TyKK6rA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovDJ5-0010zj-2w; Wed, 16 Nov 2022 07:58:03 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovDJ4-0010ym-5r; Wed, 16 Nov 2022 07:58:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=GIDdGR9NVpGZvPLCxr6Lt5iCaPSKMyIMMAkRo9Z5H0U=; b=GjO5nedtvQbFTSqVOHRhbXy9R8 wVqBzTfrNIv7JpJlixcjrIFsfztRINtv8hTfXP2xdXEzm1cusHr/wBzkJXgfC1yhvBcEie3kT73/O 01LQ4kQ1f6HUsl8HrvglXy/FRBy9LtDRvVeVVUpFuiLU2bM1O526Y4aH4dTvRXBW0GPumyvly0J8g j8A65L4jHZ6Xw5pRJSKwaDU4OJKbnsY+aJWT+IdlxO59woGeC73lkhcvx1HU3HmkmDQlDcMZG1atN c3mMvdJgqYg3ThnwdQQzL544qHjEtDzguypzVWJunrU6ZXYfGQHiHRXlUFVNS4So63yUHmxiRrkDX H//I7SVQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovDIx-00HA6L-AC; Wed, 16 Nov 2022 07:57:55 +0000 Date: Wed, 16 Nov 2022 07:57:55 +0000 From: Matthew Wilcox To: Damien Le Moal Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, Vlastimil Babka , Conor Dooley , Pasha Tatashin , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , 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 Subject: Re: Deprecating and removing SLOB Message-ID: 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> <0e45a2f2-6dd5-5a43-c1a0-7520c1ed2675@opensource.wdc.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0e45a2f2-6dd5-5a43-c1a0-7520c1ed2675@opensource.wdc.com> X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Nov 15, 2022 at 01:28:14PM +0900, Damien Le Moal wrote: > On 11/15/22 13:24, Damien Le Moal wrote: > > 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. > > Note about the last case (SLUB+patch+slub_max_order=0). Here are the > messages I got when the init shell process fork failed: > > [ 1.217998] nommu: Allocation of length 491520 from process 1 (sh) failed > [ 1.224098] active_anon:0 inactive_anon:0 isolated_anon:0 > [ 1.224098] active_file:5 inactive_file:12 isolated_file:0 > [ 1.224098] unevictable:0 dirty:0 writeback:0 > [ 1.224098] slab_reclaimable:38 slab_unreclaimable:459 > [ 1.224098] mapped:0 shmem:0 pagetables:0 > [ 1.224098] sec_pagetables:0 bounce:0 > [ 1.224098] kernel_misc_reclaimable:0 > [ 1.224098] free:859 free_pcp:0 free_cma:0 > [ 1.260419] Node 0 active_anon:0kB inactive_anon:0kB active_file:20kB > inactive_file:48kB unevictable:0kB isolated(anon):0kB isolated(file):0kB > mapped:0kB dirty:0kB writeback:0kB shmem:0kB writeback_tmp:0kB > kernel_stack:576kB pagetables:0kB sec_pagetables:0kB all_unreclaimable? no > [ 1.285147] DMA32 free:3436kB boost:0kB min:312kB low:388kB high:464kB > reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB > inactive_file:28kB unevictable:0kB writepending:0kB present:8192kB > managed:6240kB mlocked:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB > [ 1.310654] lowmem_reserve[]: 0 0 0 > [ 1.314089] DMA32: 17*4kB (U) 10*8kB (U) 7*16kB (U) 6*32kB (U) 11*64kB > (U) 6*128kB (U) 6*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3460kB > [ 1.326883] 33 total pagecache pages > [ 1.330420] binfmt_flat: Unable to allocate RAM for process text/data, > errno -12 What you're seeing here is memory fragmentation. There's more than 512kB of memory available, but nommu requires it to be contiguous, and it's not. This is pretty bad, really. We didn't even finish starting up and already we've managed to allocate at least one page from each of the 16 512kB chunks which existed. Commit df48a5f7a3bb was supposed to improve matters by making exact allocations reassemble once they were freed. Maybe the problem is entirely different. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel