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 57D41C433FE for ; Mon, 14 Nov 2022 05:48:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 790F18E0001; Mon, 14 Nov 2022 00:48:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 741276B0073; Mon, 14 Nov 2022 00:48:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E3478E0001; Mon, 14 Nov 2022 00:48:43 -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 4C68A6B0072 for ; Mon, 14 Nov 2022 00:48:43 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 15AD2A0D57 for ; Mon, 14 Nov 2022 05:48:43 +0000 (UTC) X-FDA: 80130968526.23.D4DFCAD Received: from esa2.hgst.iphmx.com (esa2.hgst.iphmx.com [68.232.143.124]) by imf29.hostedemail.com (Postfix) with ESMTP id 2B5ED12000C for ; Mon, 14 Nov 2022 05:48:40 +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=1668404921; x=1699940921; h=message-id:date:mime-version:subject:from:to:cc: references:in-reply-to:content-transfer-encoding; bh=v1sR2mwFH9dmYdHzu0koJ50qxkQ0XF8GxeWMZxBQMlk=; b=ZaMbUuILSQpWlGMWncjkuEfmwEoC8neuEB/GfZuWHWx18MN9UFBG7Wyk jg+qQ8Ar7TVrhJ9+S/gkebdKGIuLs7edeY/M4Z09GizkipqTbkoC44f79 ZauEIcswvzga5/H59DERVm9OFTL0ygVpd1hKVLfTUNCXZQBwEVJezeznr EBF/55vrrHtvkmQyGz19rgQ9rBLmThmwrX7UCuvQO8/wwTZ1BTtondQsJ Hbqx7PdEzei73tilVgW/bMAvxg54913jCi5e3ZzrLq5yBCOSjRBlB11bq +9GvQsuutpjXlx4G4S2nEv9HQqNwx6z5lkV3tP2nBF2t/a7pMYjvpmxJG Q==; X-IronPort-AV: E=Sophos;i="5.96,161,1665417600"; d="scan'208";a="320535396" 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 13:48:39 +0800 IronPort-SDR: nk54EXfaEj3bYoMATnQq0ja+QRXPe8S0MmTcP5Bh+MVj8XePv+fvFQuhUej8M9/bBsqh4JTLAo fs1x7lIgK3wUnOYJr1tFsTMtpcGotXW28rKrG7CGFdR0wyQO3UpQKdzOIIZpeDtWPSy2XkD4B3 tWTZuU2caOy14IYPYAtW4UrcJD8W9+d6kemS3b26aLG9mlKatHzTSQJR2RXvFWv9/q7pIITMDU OffT3fKLTM/DwNduYRtHrsxesVy9AUXpwx47NiaVqJUrUA3kxzPXdIj9fxZHaYrFBo8OBXjxUl npE= Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Nov 2022 21:01:54 -0800 IronPort-SDR: ZQxcu03FtMaHZ+UqMbeUZACn/n+jfWtIa8oWrCe3PiuHiJ5OeZFfAg9rLMQTvvrvOtPjjvNhYU 4PwcJE7kEHrUqL8mvSCNpXrfM/q43aJ1Z23z6pj48nEWX5RQVSsRUCnkkuYQPulZigVfNeiITq 9HNifnOkpuNd9kmXgzeR5pWPVWMIDQATdJA4R2f6MGj3BjyZ0r/A7A5dH0mxRFMuw+JIpg4tk9 D4RYfSkTNEyEyqpCeQGecKw3sAATCkMYA1aiS+xRo9IcQKhDJOoDYNM51kk7UJaV8Sdpx410HL mmg= WDCIronportException: Internal Received: from usg-ed-osssrv.wdc.com ([10.3.10.180]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 13 Nov 2022 21:48:40 -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 4N9ddz1RkLz1RvTp for ; Sun, 13 Nov 2022 21:48:39 -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:references:to:from:content-language :subject:user-agent:mime-version:date:message-id; s=dkim; t= 1668404917; x=1670996918; bh=v1sR2mwFH9dmYdHzu0koJ50qxkQ0XF8GxeW MZxBQMlk=; b=Jj+OgXCgQLjiUSHdOF9I6MrgaqryVIX7t3nKyq6ZmaxCJrCDf+D tGBRwgMUBBGTq4WU22kKDQ58BiVzcFr1xRFoFfI1n8Bxo5+TB1XvlNxdODgFNzfR jI637Q7j4BNG1aLfH2JTTKH2lh843Eo9/6TImWIKH46gMtBWsZjKCoxGm9Oozafp gcs1atYVDBJpU4XwoYUztHkasGYGgZWrc/JjNE7l3NWvxCnS7nVLlm25abnZU+4P jNICFUVM5vo+y+8k+C+JC5BZmVgZ8TARD4EmnhnyFopFQzr/VUu1urRgOa3vVo3h xfnBECv6draKEFEd/vChz733S2WF8QS+58w== 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 RcRC30UlJV0w for ; Sun, 13 Nov 2022 21:48:37 -0800 (PST) Received: from [10.225.163.46] (unknown [10.225.163.46]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4N9ddp5cqHz1RvLy; Sun, 13 Nov 2022 21:48:30 -0800 (PST) Message-ID: <93079aba-362e-5d1e-e9b4-dfe3a84da750@opensource.wdc.com> Date: Mon, 14 Nov 2022 14:48:29 +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 From: Damien Le Moal 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: Organization: Western Digital Research In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668404921; a=rsa-sha256; cv=none; b=pUs57EL7V0IN7S+mUe9yJNvqiVa9l8VQRu4mfXRmZIpPCeqPE5ZSv8IQ1zIqbYTUBwaB4Y Lc4uvidrU3RBUoRwrYcRtVuQKbp4IngEa1W0yI1jF8KvIXqpBGm+iegFqjlmkQTfA1+FqE 3lvRzTOaWWskH7SCZFiTO/7HFhGT0io= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=ZaMbUuIL; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=Jj+OgXCg; spf=pass (imf29.hostedemail.com: domain of "prvs=310906da8=damien.lemoal@opensource.wdc.com" designates 68.232.143.124 as permitted sender) smtp.mailfrom="prvs=310906da8=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668404921; 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=YFTPLoOJ0bGHdu79XmzwPF0pD5SjDnpCW8oKZYRPtMA=; b=cDsoBKrC+xjVPBcXAean0f56s2kWyGl+0JcDX9IL5PaZi5uUNcgmVKFt6zWpvXoYjm6Lp+ aRhfdKT8etnkuRLhGW0rep0KBayLx+HtqCBSilpDzMoBKNPwGA9aIN1Fo7xfRkaUl+jXU4 OEFEVpstet52EwSPHQN9bXc3umqAeRw= X-Stat-Signature: pm41oxqe4w8nrficy14xgck6qeictm98 Authentication-Results: imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=wdc.com header.s=dkim.wdc.com header.b=ZaMbUuIL; dkim=pass header.d=opensource.wdc.com header.s=dkim header.b=Jj+OgXCg; spf=pass (imf29.hostedemail.com: domain of "prvs=310906da8=damien.lemoal@opensource.wdc.com" designates 68.232.143.124 as permitted sender) smtp.mailfrom="prvs=310906da8=damien.lemoal@opensource.wdc.com"; dmarc=pass (policy=quarantine) header.from=opensource.wdc.com X-Rspamd-Server: rspam10 X-Rspam-User: X-Rspamd-Queue-Id: 2B5ED12000C X-HE-Tag: 1668404920-941931 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/14/22 10:55, Damien Le Moal wrote: > 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 :) Did further tests with kernel 6.0.1: * SLOB: 630 free pages after boot, shell working (occasional shell fork failure happen though) * SLAB: getting memory allocation for order 7 failures on boot already (init process). Shell barely working (high frequency of shell command fork failures) * SLUB: getting memory allocation for order 7 failures on boot. I do get a shell prompt but cannot run any shell command that involves forking a new process. So if we want to keep the k210 support functional with a shell, we need slob. If we reduce that board support to only one application started as the init process, then I guess anything is OK. -- Damien Le Moal Western Digital Research