From patchwork Fri Sep 8 14:53:05 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vlastimil Babka X-Patchwork-Id: 13377568 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 4A750EE8012 for ; Fri, 8 Sep 2023 14:53:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D5276B00CF; Fri, 8 Sep 2023 10:53:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75C536B00CC; Fri, 8 Sep 2023 10:53:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 433316B00CD; Fri, 8 Sep 2023 10:53:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 211096B00CD for ; Fri, 8 Sep 2023 10:53:23 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id ED0EC1CAD63 for ; Fri, 8 Sep 2023 14:53:22 +0000 (UTC) X-FDA: 81213723444.27.7E4F476 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf15.hostedemail.com (Postfix) with ESMTP id 1BD8BA0003 for ; Fri, 8 Sep 2023 14:53:20 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YuP4yGAg; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zdKRoEqR; dmarc=none; spf=pass (imf15.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1694184801; a=rsa-sha256; cv=none; b=ytcU5Z5Sg5OtOGKEdkv2FMMLu7u5zLjNECCs3I4YbFya5HqXDQwX75ihqP06iOEeCKFW5q cIrcWJxOaSp3kv7ObPunSZ7ZzqeS8k7Ypggz0IFiaweThY0n1eWxdYDedEDIrcvYorAbKY eOM/0H+MgfxNJre1nb0nwu9sokY6Y3o= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=YuP4yGAg; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=zdKRoEqR; dmarc=none; spf=pass (imf15.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1694184801; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1Z1sKJpFTH+GkYm0khClKXyg32JfDaf6DR+O1U32B1U=; b=oP7vwWkD9GqZqZdK/8GIiSMX734dAp7ixRPKkAOyxx2mlMrZsJSQJnX9FhDmE2ssu8puV4 fOvvKOvUlpfeXRqKgIr1g8CW28Iv/WIKdpUOBHioLo+OaAo89eeOvkmGb6jb22Ao7M1kV9 9k77OsU7YlhYHspLnrGnnzU1fJKf61k= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 2FCAB21D25; Fri, 8 Sep 2023 14:53:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1694184799; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Z1sKJpFTH+GkYm0khClKXyg32JfDaf6DR+O1U32B1U=; b=YuP4yGAgh8IJXJqsJ73xpH1c8mWzwQKxk19hlkWByx+xqNYN38WeOb48/N6bxU0xCx8maW W1jKRpnjfatbKB8YELQlCeuLU2hRZzscE/fnXEfChJl//ljQGtUhCDbG9stCFPzEOpYgEa m9vCuphfho6ykKwxQy2FsDwCQfrC7nE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1694184799; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=1Z1sKJpFTH+GkYm0khClKXyg32JfDaf6DR+O1U32B1U=; b=zdKRoEqR5QeAuWFifH3Asdg2OEmp22MdGD1d+kXPIOxuQfreIS8fFSyp4hCLbK4CVYH8py dB2y1nrKP4MuEvDg== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 0857E131FD; Fri, 8 Sep 2023 14:53:19 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id AMVrAV81+2QaBQAAMHmgww (envelope-from ); Fri, 08 Sep 2023 14:53:19 +0000 From: Vlastimil Babka To: David Rientjes , Christoph Lameter , Hyeonggon Yoo <42.hyeyoo@gmail.com>, Jay Patel Cc: Roman Gushchin , Pekka Enberg , Joonsoo Kim , linux-mm@kvack.org, patches@lists.linux.dev, linux-kernel@vger.kernel.org, Vlastimil Babka Subject: [PATCH 2/4] mm/slub: remove min_objects loop from calculate_order() Date: Fri, 8 Sep 2023 16:53:05 +0200 Message-ID: <20230908145302.30320-8-vbabka@suse.cz> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230908145302.30320-6-vbabka@suse.cz> References: <20230908145302.30320-6-vbabka@suse.cz> MIME-Version: 1.0 X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1BD8BA0003 X-Stat-Signature: tj6b6nzch6s835jh8eugyjbue5h8ods7 X-HE-Tag: 1694184800-960893 X-HE-Meta: U2FsdGVkX19ArIKbzdS9+yGwJoyri4jyOQYjwOQxSkUVL/L4PI1fCeiWmRfibN47FqmBKn+EWNGcAnw8GofrOOH3LS4UYiZNGJkKC+eGGh0u1IJtJ/deqMHok3gN9T3bP97ATgxnq7cwQMmGeMActjiPQy4QJ4Jzx4WxSZnaL7sOd30Dn+hYucKiIyburiRXgt7rBW+c2hyv7trmeTdWpbnLWeLBq724UTr/NDzUf535GWyTBLOF9K4Xxsh48nkt+mBTIb8pkIBRUcQYocBiL+OT/Mp/lT6/4r30y69ckI5T1+ajqgkd3eriWSkLvkLGLMFr9onokG5fg2EL4iKO5oG7Ogg2az/PQQKYmgKkG67OwNEcprjHwiHWoFlS/kJs44RKU3/7oq8BLaBwheYU6AWe6I0rmj3uSupCdF4u1cilzOHxJIL1ntf3khrGFiEZuR2Xy44LdV7egAFrj6sHCJ8Rno46k1TsTfeF0ayNjG+TbIcNjeoDLqFDAWj2Il9LryxnTqLROgTZPis15l3L2vDE7RWQncJLCpnW87L9iQzWdwnOyfaDNh1TR09WMboZ+Vu3GL5elOVr/MtcVs0OXGGnztGe91mvued2s/8rNeq7D+tlh3fyWZZzmW0HpFQOYDjbXBpUSzkPM5PRqLCcqh1wzk+4wVGDx6BUE4/pF2NkNZwOEre5aN91HzaMhHKFZssbIWKqf6KAWnmi7ZhxVnL6Ssbvjfn08q5OQwhs6ziqd+iGgzPluYRzUxQHVeRCYj8YmsDEA/FnP+dWo/xgebFT2zPfvlDp2Z2XSbB7Gxl+hbVzElFXQvaeEHJHMpjJN/9DA8/qPauMrw+p7Pu6FS8nNgyENsDk0BVRieFKyKlpejf+BSpaeFXp9Gp5t/8hlpUnUCUqt3o/BdUJ/QO92dyrfzPrx9UZebvCxjCsTQyu/yrA1EV40NZUjKUhpboPU6vupdbp9i802gSydlO DFx9lLcn kYaWw5PapLq2BgKpWEJXvkFoj9695QSkR/fyF4D+IYVuUxV7eaAkfG5Um6ZRiG4LO9hzBiMpoRR44//wLOaqVX3fNn2D+v9+ESSv4nGvJx5lKBxFPlAu2l/I/x3TQZhh9B0XDVlnV5pW5fkpIqe36gSY/lpFCLEvYVJKerTf6zL31kI9G00R5vxf1li0GnsiphllhrgmNFYDWJVnzpRxA60ETQaIkp6c8d4jSqXMeR6dI1Btxs9nfmD7kFqjQoGlQ4OfCa/i529wRZUOMZQwarsn9Yxd6h7DOP9EOXKXfCL7TRdUs/dmvMevwRg== 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: calculate_order() currently has two nested loops. The inner one that gradually modifies the acceptable waste from 1/16 up to 1/4, and the outer one that decreases min_objects down to 2. Upon closer inspection, the outer loop is unnecessary. Decreasing min_objects could have in theory two effects to make the inner loop and its call to calc_slab_order() succeed where a previous iteration with higher min_objects would not: - it could cause the min_objects-derived min_order to fit within slub_max_order. But min_objects is already pre-capped to max_objects that's derived from slub_max_order above the loops, so every iteration tries at least slub_max_order in calc_slab_order() - it could cause calc_slab_order() to be called with lower min_objects thus potentially lower min_order in its loop. This would make a difference if the lower order could cause the fractional waste test to succeed where a higher order has already failed with same fract_leftover in the previous iteration with a higher min_order. But that's not possible, because increasing the order can only result in lower (or same) fractional waste. If we increase the slab size 2 times, we will fit at least 2 times the number of objects (thus same fraction of waste), or it will allow us to fit one more object (lower fraction of waste). For more confidence I have tried adding a printk to notify when decreasing min_objects resulted in a success, and simulated calculations for a range of object sizes, nr_cpus and page_sizes. As expected, the printk never triggered. Thus remove the outer loop and adjust comments accordingly. There's almost no functional change except a weird corner case when slub_min_objects=1 on boot command line would cause the whole two nested loops to be skipped before this patch. Now it would try to find the best layout as usual, resulting in potentially higher orderthat minimizes waste. This is not wrong and will be further expanded by the next patch. Signed-off-by: Vlastimil Babka --- mm/slub.c | 38 ++++++++++++++++++-------------------- 1 file changed, 18 insertions(+), 20 deletions(-) diff --git a/mm/slub.c b/mm/slub.c index c6e694cb17b9..5c287d96b212 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -4141,14 +4141,6 @@ static inline int calculate_order(unsigned int size) unsigned int max_objects; unsigned int nr_cpus; - /* - * Attempt to find best configuration for a slab. This - * works by first attempting to generate a layout with - * the best configuration and backing off gradually. - * - * First we increase the acceptable waste in a slab. Then - * we reduce the minimum objects required in a slab. - */ min_objects = slub_min_objects; if (!min_objects) { /* @@ -4168,18 +4160,24 @@ static inline int calculate_order(unsigned int size) max_objects = order_objects(slub_max_order, size); min_objects = min(min_objects, max_objects); - while (min_objects > 1) { - unsigned int fraction; - - fraction = 16; - while (fraction >= 4) { - order = calc_slab_order(size, min_objects, - slub_max_order, fraction); - if (order <= slub_max_order) - return order; - fraction /= 2; - } - min_objects--; + /* + * Attempt to find best configuration for a slab. This works by first + * attempting to generate a layout with the best possible configuration and + * backing off gradually. + * + * We start with accepting at most 1/16 waste and try to find the + * smallest order from min_objects-derived/slub_min_order up to + * slub_max_order that will satisfy the constraint. Note that increasing + * the order can only result in same or less fractional waste, not more. + * + * If that fails, we increase the acceptable fraction of waste and try + * again. + */ + for (unsigned int fraction = 16; fraction >= 4; fraction /= 2) { + order = calc_slab_order(size, min_objects, slub_max_order, + fraction); + if (order <= slub_max_order) + return order; } /*