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 DED09C4332F for ; Sat, 12 Nov 2022 01:43:33 +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:From:References:Cc:To: Subject:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=1WEX+Iy098QbS/DGvcI9t0DEeRABLCJsfmUJi3RZjbU=; b=jWiAcWMclvEx83 SRNapIsY/Odl8CkUnFQI2hd7YLILFjjoubLzEiOCbk5TPQg02CjIWHk6UMv8npkpZI4XjYwBD/e1J GEzdSNacPrQJRVlYSFb73oxOLe7B4L4F5DfK9nrMLOcNk8ozpb8CunPkrh+hqb1DZanzCOv7F4gzO d11JRTNwnTfbg1ouQFo9ttR/r71MXGhri1iZsE+oa02K/1wsPaOJWpgRpruiRBHhJmmg/6asIR8+G Wu7X3cObxWnATebopS/l+Lx6i3EzzWRlV/Z1YRb03wZQWOBiPRfJopo9fF0CQ8yXcvbPHMufmyWnq 0pruM0T1FrJ/vE2b8I8A==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1otfW9-002Onw-RL; Sat, 12 Nov 2022 01:41:10 +0000 Received: from esa4.hgst.iphmx.com ([216.71.154.42]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1otfW6-002OjB-Gm for linux-arm-kernel@lists.infradead.org; Sat, 12 Nov 2022 01:41:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com; t=1668217266; x=1699753266; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=kWfbDk7epBE8N+lvIUYGuQa6NGCEfO5LUkxzV91Rv/U=; b=cT3aFb2NBVHnffap7Ej1cC+BCw0NwTEtePkrc5KrlvK1BqROGlJ9bG6J QqTuksgRoZCQ+db795RRPNiAx/Q3VjGcWadWp3kHllLRebvckZfiRLy32 n7zC9IFBAQhMpa+jP4tdDsNF8rsofX3uXEQZmUHrBhWTWe66eT+EGi/mp z4fa94QqKEMmYmqlqh09bAGhislCEYCq6xLcYFyxk4r2jrBsWd4UPmuRj 0UFeTPQ2tMwUH4c/y0/6sIro5lG/NOeurxEywqjE1gcztBw/oHhuz8x58 osVNJZlfh0EvmNQqmXZO8F7CbwCjHOE+6WSpXfAqXM4bgm7BMU6wuf5qv Q==; X-IronPort-AV: E=Sophos;i="5.96,158,1665417600"; d="scan'208";a="214366055" Received: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 12 Nov 2022 09:41:01 +0800 IronPort-SDR: p4lh6xrCW2kP/W2jq/P/bg52MCTXBpJStxSHxmDthaHHL9JQdyjJWdtVhevdzdvCnLRq65LN6W w/IGTxH9U5vIxHKP+AItbqnbtzrfZ7ALtPeQO1kqhog6/F0YB05jdJnmz22aN0sltstH6kUL93 63om2dfflfd9eXgzu3Z5QZxiangBYPDBvlLnTu7Cg5En9rNQclI6pTscQLCHvBnUK6FO/obyN0 +XIolqTcvIy45xpkBkxbPcU+S27di0DQWQhGBA5P48GjS1r+eczQIV80MgTastLIQHY+SnGT5t z6Q= Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 11 Nov 2022 17:00:03 -0800 IronPort-SDR: 5p7AuR264fDQcj8aPkyKLGKIvSecwpKqBuuK1yNdgtn6lS6BqqWCyS3wU0huPnWGYyzTlN2iJW sofw0BtRgl0ndvXm2YZWwYJ9g1ZX8rD/kJvGhNesN3Eo0ZxFLpqRnjaFfkZUgbL3T5CkPnu4kM 0VEJiUyWhP6wxuuU2WXQwlGc5OhV6Mkf418UCd1D2C31XrOL1ES+ZE8+tXhHz+HE805FcYM80Y VDm+w5r36G+jlqg2zwzgpdiQWGd/u8JOetQPfdM9rGkrloyPqeoi5vzbDp02GE6hYTKmjp9lS8 CjI= 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; 11 Nov 2022 17:41:02 -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 4N8JF91dKqz1RvTp for ; Fri, 11 Nov 2022 17:41:01 -0800 (PST) Authentication-Results: usg-ed-osssrv.wdc.com (amavisd-new); dkim=pass reason="pass (just generated, assumed good)" header.d=opensource.wdc.com 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= 1668217259; x=1670809260; bh=kWfbDk7epBE8N+lvIUYGuQa6NGCEfO5LUkx zV91Rv/U=; b=Xt/iwKvzhSDgTK+B4NYDMAfHOtqp1/lm6m42MJplgxGQ/MhvZcg DiL5QupgB6hf9pSwls6trrK2Go0lAWor98lJ4CXB77UDfuOK8rMfb22YZtw3Pweh pFj4HQ927gmUPDBO38wl7Ip+uoDPouRj5UdJclRCe++QlSW4WcwEB3zS5c8/17Ya YhnZhArolHjrAo5SLDsgoQhohh2WglL66ga54503AkORVEj09pZexQratT96uFEg DOJmCaIsPpNzz8oZtvgW5YPUcKo1AebpsvfRu1TW7iW9MlkGGHlIGrFDC6Iq1pLS oVQLQj32vK2wFWj3Sp1cTHoo024dHRz3qSA== 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 S_h7dznZ1Abs for ; Fri, 11 Nov 2022 17:40:59 -0800 (PST) Received: from [10.225.163.43] (unknown [10.225.163.43]) by usg-ed-osssrv.wdc.com (Postfix) with ESMTPSA id 4N8JF265dcz1RvLy; Fri, 11 Nov 2022 17:40:54 -0800 (PST) Message-ID: Date: Sat, 12 Nov 2022 10:40:53 +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: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221111_174106_679155_DEE5B668 X-CRM114-Status: GOOD ( 25.10 ) 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 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 will try with SLUB over the weekend. -- Damien Le Moal Western Digital Research _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel