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 6161FC4332F for ; Mon, 14 Nov 2022 01:55:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6E0156B0072; Sun, 13 Nov 2022 20:55:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 690406B0073; Sun, 13 Nov 2022 20:55:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5097D8E0001; Sun, 13 Nov 2022 20:55:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 41DE86B0072 for ; Sun, 13 Nov 2022 20:55:21 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 00A38AAB01 for ; Mon, 14 Nov 2022 01:55:20 +0000 (UTC) X-FDA: 80130380400.16.DDCF24F Received: from esa1.hgst.iphmx.com (esa1.hgst.iphmx.com [68.232.141.245]) by imf17.hostedemail.com (Postfix) with ESMTP id 0280940002 for ; Mon, 14 Nov 2022 01:55:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1668390919; x=1699926919; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=nyOFTXz3d9X6eMOZsmuYqPSZyAOtJSgUq3fJ16zqsqM=; b=YAgtcDHyrE74pRquAee99zY83Qq5qoCaBc//5rLzh6VnnrxkLLBbOOBk VO7BzkcvNhMEx8H7uRHPO/NJLWVCOIqaDJ7j6lE6qEA1Q9/o6pLxMPSYT HIxZECuef2WiB5b3EUQ9OkpyUMRHkHgF+QFR0ZwmUw3PXuD198GyKH7iZ BbKFhg9Um9tsoFbA3izwXMfZpUsUq6xbZ5sUgJZUf0mm/hNaFRsbmm4sS PYctDL9NeQWC7kLfJD46LQVw8T3vDMzTcm3XQLUSuPCLz+W31Jewyr14a GfnjM2THOouqik6qcrpuFIJ7Vrk5ci6ImQI+MLtnb6jQH6SdT5Yys0gFA w==; X-IronPort-AV: E=Sophos;i="5.96,161,1665417600"; d="scan'208";a="328277997" Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 14 Nov 2022 09:55:18 +0800 IronPort-SDR: sNl5BbkvBZdfVx2CJ212ItTFpPDVjE/lW+gF97Y2He/YK9ZNvurt5sLICZruXWa5Ed4GcAxuXb G7cK96Kqi1JNDNLgdWxfMWs3fiUYEEPxVwrhqnPMAln9U2iLYsq6Gzt44s+HdSHT3pkLrqhWQF fxf1uNfbHYm0H6OQ5n3cIv7U2sgRfOoTjRbFMHSLB7XXKBYJPXpCrJLzUnGWJpo20C5XltmeFr ULWguNvdmOfZj5Rc+bnJKqn3Hv3hr/tUd3d6vO2m95kuJNw//meTu6QsioA+NNhUfsuf1VtVFR 5ag= Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Nov 2022 17:08:32 -0800 IronPort-SDR: 6HwbdAkuyLePi6cdGUEmqbi4yEYXqJwotxfk/sQlOIwt6+FcnY7QegkYdy6xmqmTQ4ln5m6STp ZDKkTjxEeIA3l1V4JJc6G6Ne0uiacRiAFiKbUxTEwR5RX/3WRkBkBrrO4IwO4XoQYoGtZs+M8T Yee3a/0cmXpwxOuxBWNtk+AykqheaozYOqoQp+JbCUi1imzufhCpD3dWNqn/oc2WNfUgLdzwym r/Kgv4sV6nN2SfGJ+RFbDQITX7kcyXEpo+NT01lDessEijbecmbkvo8lnhqhDbVVv4R7yFeWf6 vfY= WDCIronportException: Internal Received: from usg-ed-osssrv.wdc.com ([10.3.10.180]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Nov 2022 17:55:19 -0800 Received: from usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTP id 4N9XSj437Gz1Rwrq for ; Sun, 13 Nov 2022 17:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= opensource.wdc.com; h=content-transfer-encoding:content-type :in-reply-to:organization:from:references:to:content-language :subject:user-agent:mime-version:date:message-id; s=dkim; t= 1668390916; x=1670982917; bh=nyOFTXz3d9X6eMOZsmuYqPSZyAOtJSgUq3f J16zqsqM=; b=B7FIG24k/AkrbPRlxTTp+YAyPl2DtgOB49NBmCF1uJe1rzavO/J NnzQvOw5y6jZvpQDwbtMGe43anknJxLtaNq6ye3vNETqunaV7aPGbWlB5yTcJneZ dep7KJ5wOdey9UA9pJO55QieVSkTNlBVhNgkyYu31fgMtYTbglkkIlf7pD0mZS9U TV2BXR5pUYz63ZjDo3FL0DtWJD6Q7xWT2ajGfhM6MNxiQ4WATwU3nDj6s5pOHaUi EtT3fitwsRCuczjPghjRbOWkaSka9UnIqihDhmL1YAsBAgEnAIKojathaHJVhQgy vt64Jcr8YksY1GcywsWLEhEhXqIrpmbW4JA== X-Virus-Scanned: amavisd-new at usg-ed-osssrv.wdc.com Received: from usg-ed-osssrv.wdc.com ([127.0.0.1]) by usg-ed-osssrv.wdc.com (usg-ed-osssrv.wdc.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xlwMu3T2NAzr for ; Sun, 13 Nov 2022 17:55:16 -0800 (PST) Received: from [10.225.163.46] (unknown [10.225.163.46]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4N9XSY61WPz1RvLy; Sun, 13 Nov 2022 17:55:09 -0800 (PST) Message-ID: Date: Mon, 14 Nov 2022 10:55:08 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: Deprecating and removing SLOB Content-Language: en-US To: Conor Dooley , Vlastimil Babka Cc: Pasha Tatashin , Christoph Lameter , David Rientjes , Joonsoo Kim , Pekka Enberg , Hyeonggon Yoo <42.hyeyoo@gmail.com>, 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: From: Damien Le Moal Organization: Western Digital Research In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=YAgtcDHy; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=B7FIG24k; spf=pass (imf17.hostedemail.com: domain of "prvs=310906da8=damien.lemoal@opensource.wdc.com" designates 68.232.141.245 as permitted sender) smtp.mailfrom="prvs=310906da8=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668390920; a=rsa-sha256; cv=none; b=Vyp9xkM43wPeBnJZ6AfRUlLrBmrBXjOgXY+fruAUt72yt4Z/dBvDuMb9HEXrUxwF3lgOpl /SwJ+lucPvIFHhI3rPwvaIKyReSXjNOWmPCb9IcIVNN0nDdIrayrvdMEEpCWCDMDLhdU/I tgYke3DKNkvHHSKbeQCc5HYZtQ0rQfM= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668390920; 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=zKbg2IIsIiuEMl+XTb5zgSedM/S8T2xDwjKXWgU7LFI=; b=T9CzPd0eL90TAqW6JmA4OD1fI7fsfp9VrXrPOvHykP04xTJcz7qK7DsMjFb6a6oZo4Umlw TKL0tDQP65V+7wSeGVecIEH78YrRC3beNoaBCMlRuZy3TMu3IjCz1D4uyF7HI6SIUOLGID IJ5DiExsBr/pA//mfDix5FI2FsssAkQ= X-Stat-Signature: 4mhoiq1sd88ua1fgkp7nfhgpgnxqym8w X-Rspamd-Queue-Id: 0280940002 X-Rspam-User: Authentication-Results: imf17.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=YAgtcDHy; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=B7FIG24k; spf=pass (imf17.hostedemail.com: domain of "prvs=310906da8=damien.lemoal@opensource.wdc.com" designates 68.232.141.245 as permitted sender) smtp.mailfrom="prvs=310906da8=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com X-Rspamd-Server: rspam11 X-HE-Tag: 1668390919-770646 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/12/22 05:46, Conor Dooley wrote: > On Fri, Nov 11, 2022 at 11:33:30AM +0100, Vlastimil Babka wrote: >> On 11/8/22 22:44, Pasha Tatashin wrote: >>> On Tue, Nov 8, 2022 at 10:55 AM Vlastimil Babka wrote: >>>> >>>> Hi, >>>> >>>> as we all know, we currently have three slab allocators. As we discussed >>>> at LPC [1], it is my hope that one of these allocators has a future, and >>>> two of them do not. >>>> >>>> The unsurprising reasons include code maintenance burden, other features >>>> compatible with only a subset of allocators (or more effort spent on the >>>> features), blocking API improvements (more on that below), and my >>>> inability to pronounce SLAB and SLUB in a properly distinguishable way, >>>> without resorting to spelling out the letters. >>>> >>>> I think (but may be proven wrong) that SLOB is the easier target of the >>>> two to be removed, so I'd like to focus on it first. >>>> >>>> I believe SLOB can be removed because: >>>> >>>> - AFAIK nobody really uses it? It strives for minimal memory footprint >>>> by putting all objects together, which has its CPU performance costs >>>> (locking, lack of percpu caching, searching for free space...). I'm not >>>> aware of any "tiny linux" deployment that opts for this. For example, >>>> OpenWRT seems to use SLUB and the devices these days have e.g. 128MB >>>> RAM, not up to 16 MB anymore. I've heard anecdotes that the performance >>>> SLOB impact is too much for those who tried. Googling for >>>> "CONFIG_SLOB=y" yielded nothing useful. >>> >>> I am all for removing SLOB. >>> >>> There are some devices with configs where SLOB is enabled by default. >>> Perhaps, the owners/maintainers of those devices/configs should be >>> included into this thread: >>> >>> tatashin@soleen:~/x/linux$ git grep SLOB=y > >>> arch/riscv/configs/nommu_k210_defconfig:CONFIG_SLOB=y >>> arch/riscv/configs/nommu_k210_sdcard_defconfig:CONFIG_SLOB=y >>> arch/riscv/configs/nommu_virt_defconfig:CONFIG_SLOB=y > >> >> Turns out that since SLOB depends on EXPERT, many of those lack it so >> running make defconfig ends up with SLUB anyway, unless I miss something. >> Only a subset has both SLOB and EXPERT: >> >>> git grep CONFIG_EXPERT `git grep -l "CONFIG_SLOB=y"` > >> arch/riscv/configs/nommu_virt_defconfig:CONFIG_EXPERT=y > > I suppose there's not really a concern with the virt defconfig, but I > did check the output of `make nommu_k210_defconfig" and despite not > having expert it seems to end up CONFIG_SLOB=y in the generated .config. > > I do have a board with a k210 so I checked with s/SLOB/SLUB and it still > boots etc, but I have no workloads or w/e to run on it. I sent a patch to change the k210 defconfig to using SLUB. However... The current default config using SLOB gives about 630 free memory pages after boot (cat /proc/vmstat). Switching to SLUB, this is down to about 400 free memory pages (CONFIG_SLUB_CPU_PARTIAL is off). This is with a buildroot kernel 5.19 build including a shell and sd-card boot. With SLUB, I get clean boots and a shell prompt as expected. But I definitely see more errors with shell commands failing due to allocation failures for the shell process fork. So as far as the K210 is concerned, switching to SLUB is not ideal. I would not want to hold on kernel mm improvements because of this toy k210 though, so I am not going to prevent SLOB deprecation. I just wish SLUB itself used less memory :) -- Damien Le Moal Western Digital Research