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 EF6FCC07E98 for ; Wed, 29 Nov 2023 21:20:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 265886B03E5; Wed, 29 Nov 2023 16:20:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 214ED6B03E6; Wed, 29 Nov 2023 16:20:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 105196B03E7; Wed, 29 Nov 2023 16:20:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 0163C6B03E5 for ; Wed, 29 Nov 2023 16:20:38 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C9F05140660 for ; Wed, 29 Nov 2023 21:20:38 +0000 (UTC) X-FDA: 81512260956.19.08E5ABC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf21.hostedemail.com (Postfix) with ESMTP id 8E4141C0002 for ; Wed, 29 Nov 2023 21:20:35 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="Trk/qX+6"; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701292837; 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=snbaImfv3zlormUNSdyLXEJtHqS0syGmg48S3ZeIobc=; b=mOVUyrGwSnZkT9Jlc+e4SYH6IH989fZ2zpjk6KQsGK5upHxnzYhH2uMQLhngkzmDA86Q5x zWBrDPPfl6o08n9ECCP8dGfW0yvcQaEQU3A8veld/nT5CptrKqmVdWRgiP9aElcgZQQz2J qWBNdc5gNM0Q55FSijKNn72wutFlE78= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701292837; a=rsa-sha256; cv=none; b=GP9k0A7fGdAn2Bugrccsqz8hGkpb9NH6f0DBwkkPyfLayUsc/HF8eQK1YmIgz8QZP2TyaO tEotFee3f9N0JdjLrk6bkBjzXSngHvsrlUkND6XxpxTXHswwDCYxxCMSDP5XghnCkZPkwS xua9qoU9IELP6CQ/rcWcHN7DAzEMZDk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="Trk/qX+6"; spf=none (imf21.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=snbaImfv3zlormUNSdyLXEJtHqS0syGmg48S3ZeIobc=; b=Trk/qX+6KUWoedcteU9LE/hnH5 Hat6hae4Rg2zFyMNluwy2WNp+EZqrL0Ch4RpT6m/04u4PVnbx/q0YkObKt+r2uOq95KQHpMjUuduM Ac6lKR+C4O8pLAfEu2sZjZCupkxHzY0TU8LDwSu23fvgo02b0zS9Kiv//i44dIFdrOJ8qNph3vnEx SjCLb2Vq6ryo7VXYqkxU8g7Kk+fsdvEExQNuDZ108RqbXdN2ejU0KOFoiMYgaxfzmxyBFf8HinvOw NOraHyXRg3RdaR/Q8FCye3m7CbTjL+rDchu0L7d27uB6gxokLkm4es8hr8XqiqKKvefBPgkF0criY U3sY2eMA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r8Rye-00Dm4H-GD; Wed, 29 Nov 2023 21:20:12 +0000 Date: Wed, 29 Nov 2023 21:20:12 +0000 From: Matthew Wilcox To: "Christoph Lameter (Ampere)" Cc: Vlastimil Babka , Pekka Enberg , David Rientjes , Joonsoo Kim , "Liam R. Howlett" , Andrew Morton , Roman Gushchin , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Alexander Potapenko , Marco Elver , Dmitry Vyukov , linux-mm@kvack.org, linux-kernel@vger.kernel.org, maple-tree@lists.infradead.org, kasan-dev@googlegroups.com Subject: Re: [PATCH RFC v3 0/9] SLUB percpu array caches and maple tree nodes Message-ID: References: <20231129-slub-percpu-caches-v3-0-6bcf536772bc@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 5xpse13b81ctb19e58f3jp59npia1ou5 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 8E4141C0002 X-Rspam-User: X-HE-Tag: 1701292835-396975 X-HE-Meta: U2FsdGVkX19OMlElNH95KCCw8zyFdFNOmiBk3WAxc0MQlRA2o6pIjO+SWmA5tc2BjWqZc22LP/UMw+cRaRglwAiRL5Om4a6DIA59iwrYGBzxhwKdP/vjLrJFZoqt74mJ0ahMklyXqtjp4Y1whcTnH54pTxmQyKjECS/IzvBO/nBjvE/mMfdjoCWXbyxyjVKPUCihwd79NGLQPsTO7XJvjPk/CL1ABPVlAvKHYWgGQE3VBE5KzVVfPzyhZTDcMLQ8Dtbwas0TeET27MoJurerxxbzJP/0ieCe/yCJs8TfTVg+tJ6l3yFBwd586KaM7KRfDLYMuCWBDQej6Mg2aSE/OV1PoSsJas6h84R5wA8loF3Kz0rLySqDAmwo2Tk/3g1BKrPBrcrcoTgaIBpSUBXPwOXy0mxeK0P4FIIToMaoHfUYEk9rdmKiARtCqGVX8erDuthLaDxKYNqPaCci/nhejBG8my+Nb7NzjSr4W0NQqT1nJkgtooPEyBHD8zckSVzAMACT2sIapzv/NDTtJnuk0gRYkd47TfFAuu8WjdUY4OyY7x0AJyD4pX27KxGz8mDgUSB7s4P+jDtt2IeIjebpkFX5hChg+BRuGR2BlHKSPEji6u0KX4nemxx4HP/r096j/TSwa5dNg+eQGYA0fdOtLk2DkytgSnyPVOQ1GvjdLLz6j9mQ6kjYEPGGWnuvOIrVknP9ZKdPfUR+3euQOoqBZtl85JRUcg3YgIQPe8/PvWiSYXMMhTRNu0OcKe465BPd2PyUXNCfmZrQQat6p4anxAuh5uo0HgXW9rF0O/uE32UlpihoFeDwdbAtMnz5Rpb/dGo2+LG54JMobjyuD4/6FbYcnQk5qnXHZYag6Bc6FvZhrRkICWgKbL2eap1pb4SqhBtT2/yDUjBbD9OZ6+AfzxWwjxzIAiDfFMzO8GiNZa2Edkti7yLtWCpcNUPQ3eaBzGKjHgyKo5UTSxPfNfj rnoZVgR4 xFBBY3XL2Mr6C14RNkOmYmGpU7y5eDnyPPEsXaDIvP+tSOI4iVNbNl23RHBKb1oaM4hUxYAJ8WlTJ8nMcI44vxGgdJTKDR6FwTrFlNqk+B5WMTnC08SYLG3aHYP8DvS78PLOTq+U345g9aU3+/z95GpQlctw4I/bcS2+Oa8aSy5vwCsxWh6o5Y1NpR53LiOOM34wVjWnHLpQMRGR08xNzW3QP0Q== 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: List-Subscribe: List-Unsubscribe: On Wed, Nov 29, 2023 at 12:16:17PM -0800, Christoph Lameter (Ampere) wrote: > Percpu arrays require the code to handle individual objects. Handling > freelists in partial SLABS means that numerous objects can be handled at > once by handling the pointer to the list of objects. That works great until you hit degenerate cases like having one or two free objects per slab. Users have hit these cases and complained about them. Arrays are much cheaper than lists, around 10x in my testing. > In order to make the SLUB in page freelists work better you need to have > larger freelist and that comes with larger page sizes. I.e. boot with > slub_min_order=5 or so to increase performance. That comes with its own problems, of course. > Also this means increasing TLB pressure. The in page freelists of SLUB cause > objects from the same page be served. The SLAB queueing approach > results in objects being mixed from any address and thus neighboring objects > may require more TLB entries. Is that still a concern for modern CPUs? We're using 1GB TLB entries these days, and there are usually thousands of TLB entries. This feels like more of a concern for a 90s era CPU.