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 CA5F1C7618A for ; Thu, 16 Mar 2023 20:21:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 48F9E900003; Thu, 16 Mar 2023 16:21:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4185C900002; Thu, 16 Mar 2023 16:21:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E0BB900003; Thu, 16 Mar 2023 16:21:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 1AD91900002 for ; Thu, 16 Mar 2023 16:21:00 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id DEA278158A for ; Thu, 16 Mar 2023 20:20:59 +0000 (UTC) X-FDA: 80575880238.21.6619694 Received: from out-11.mta0.migadu.com (out-11.mta0.migadu.com [91.218.175.11]) by imf22.hostedemail.com (Postfix) with ESMTP id D38C1C0009 for ; Thu, 16 Mar 2023 20:20:57 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="d6nBC/+O"; spf=pass (imf22.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.11 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678998058; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tp+E+qKzkiPQ9TteUgVP64dlXuOyGgf7R5+zJuVjYSM=; b=oVsJCXkvL6EKt5ZAtX5hv+UPrANy9Aj9J4eveyHJlBGXateCUN3VKfHGRmGg5uiGQyBfpe JV1Ho+nosubexieSudwIYPAZuHWeMahEYv/myi5IK1ZdgYLTu5pJ/PYOTjHSi+KlPU+GGW Ux365MORZbc2V1zFkYWVvYzqN47nJ3I= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b="d6nBC/+O"; spf=pass (imf22.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.11 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678998058; a=rsa-sha256; cv=none; b=E+jtUSMq0Iar7OcCesoAU/wBCpncvh7MbTSC738JKiMllPPq4NpXNtt4u28h/2W4tibDbC LbNXPv0+ZvA0/qmAax1+pPNkhpqUBcCCzCJzxlnaQlbiAbp2fYCuEG6tireg4nFIO3REMJ yV69UpZJ0NoIQxtm8uljr0Pn0xI70ac= Date: Thu, 16 Mar 2023 13:20:34 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1678998054; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=tp+E+qKzkiPQ9TteUgVP64dlXuOyGgf7R5+zJuVjYSM=; b=d6nBC/+ODd1bTK9Q0IPFjyCGN1iQ02clc+m2RmLBYjreQBYklevSuN12MY7zhDZjQX/XWM VH0dJshY6vsOTIgSNvH2twCYoS966PkaQTYkn8xGjN7yqVdR8+ou9+ZfNhW5XLkVjv14Yd nEqedL4bgTd8PmyOyZoYuY5h+zdPyFY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Vlastimil Babka Cc: lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, bpf@vger.kernel.org, linux-xfs@vger.kernel.org, David Rientjes , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Hyeonggon Yoo <42.hyeyoo@gmail.com> Subject: Re: [LSF/MM/BPF TOPIC] SLOB+SLAB allocators removal and future SLUB improvements Message-ID: References: <4b9fc9c6-b48c-198f-5f80-811a44737e5f@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: g4xtanrmd9j1caginacbqw6qywpo4xb9 X-Rspamd-Queue-Id: D38C1C0009 X-HE-Tag: 1678998057-76590 X-HE-Meta: U2FsdGVkX1+Sq9I7t1oQwpupv3sv92AhPyKxERITiV+etZN/vS56Dvlugeeti8PSWAi20I/g1bjm0xmQHUHKj0IKiTCbZXZksMvkXjCySWfLQhsxUg+giE88WGJysxA33ybK6eBrvYu1fkzuwJBHifMPJuWVnBJF/ev3oUqMlAoJPzgTBuBsGPAhBOUjr32xg4UN5U3EdSZAtcDi9FW4Q8zJSpy6MetEetU/UV/M0iqoq/3Y5cPd2/xnVZi/uDZ+kXrcUtEsM/6p+Vl38pLXXODS7RI0WrpW0/EeAyjvOruNTKoyElYCWBZ7ZEfpw+SnbcTD5ujfAZQIG9HVVpsURIiI6VS0k8+YWz+uq+44slWDD7UuZqdXIQ2t7dxrPH56xGjJB9THhg47WdqA3kh2aHU5SaZaJNOmRjJNvWOrlM0ERrSaEmlkb2VRu/YQL7Ppd+4xZ7wCFS1240nGjriL+dgAjuPCM+6YIozsiQJaZIDGp2G+fQWS1a3rTUFwbtFodrqy+lsATlZw5euP7BJhrPLnVectjwRAw1QzWsdOhjeVHEu31+KEE7JKQW/pqUcsL/xGj1Lhs5L/AWGx1xyVchZNdJ9rriZKqYuwRcOHoAy44DMtaNBHWKgYvyb7q0v/+S5U3U0f/ruJW9yMw7BQCuHfayD4hxAR63cC0Pm+kDLS6pghWjp9tNAQrpML3A/VipMat2UUkYg/JI7akA5ueK/K69MZbC0ePa/nv6raccHEIgSoA5cuCmwe3JTjl7n3cj9PYp/ndsxp59dcoGT5VO7KG2q8gjAyl4uyicoMaocl4ignxABsqVkBFcpY8yztEQOwNQNEsNXAQqgQnvRFaUAXkaWUagpYmqx76WVsU4AhgBpX2n9W5opjNv8HxLSPPwht30ZjGFhcto240W5PZ/X3UvszDygWopCWaN+Z30YL4BbetTmfwut3QqXbYK+NSdXUvp8E+NC3faP2GLA XOimKcum dnP5VgtQMkszRKHdh0KFVys6+PO4oJcJSn39bQp8vnwrxT32/S2RA6KgM4emXyWP3X7EVJ7sQ0IAhzyAcUdp1OAjVDBUWrbaGt1A8zEghAaO2khgB18DsSQj6AGVM+58edYkZYzcaEIHvVIrJxAxkuvtGTVw0y/V2kIA79Xhaccf4/Ednvmbjw710PYOef9yRM/frKhEjYNKigXXc+yrlGgVGtiH2ze1x5I9L 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 Thu, Mar 16, 2023 at 09:18:11AM +0100, Vlastimil Babka wrote: > On 3/15/23 03:54, Roman Gushchin wrote: > > On Tue, Mar 14, 2023 at 09:05:13AM +0100, Vlastimil Babka wrote: > >> As you're probably aware, my plan is to get rid of SLOB and SLAB, leaving > >> only SLUB going forward. The removal of SLOB seems to be going well, there > >> were no objections to the deprecation and I've posted v1 of the removal > >> itself [1] so it could be in -next soon. > >> > >> The immediate benefit of that is that we can allow kfree() (and kfree_rcu()) > >> to free objects from kmem_cache_alloc() - something that IIRC at least xfs > >> people wanted in the past, and SLOB was incompatible with that. > >> > >> For SLAB removal I haven't yet heard any objections (but also didn't > >> deprecate it yet) but if there are any users due to particular workloads > >> doing better with SLAB than SLUB, we can discuss why those would regress and > >> what can be done about that in SLUB. > >> > >> Once we have just one slab allocator in the kernel, we can take a closer > >> look at what the users are missing from it that forces them to create own > >> allocators (e.g. BPF), and could be considered to be added as a generic > >> implementation to SLUB. > > > > I guess eventually we want to merge the percpu allocator too. > > What exactly do you mean here, probably not mm/percpu.c Actually, I mean mm/percpu.c > which is too different from slab It is currently, but mostly for historical reasons, I guess. In fact, all is needed (I drastically simplify here) is to replicate an allocation for each cpu, which can be done by having special slab_caches with a set of pages per cpu. I believe that in the long run the percpu allocator can greatly benefit from it. The need for the performance and fragmentation avoidance improvements grows with the increased number of percpu applications. But it's not a small project by any means and to my knowledge nobody is actively working on it, so my comment can be ignored now. Thanks!