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 749BDC433F5 for ; Mon, 2 May 2022 10:00:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9B836B0072; Mon, 2 May 2022 06:00:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B4A996B0073; Mon, 2 May 2022 06:00:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EAF86B0074; Mon, 2 May 2022 06:00:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 8EA1A6B0072 for ; Mon, 2 May 2022 06:00:47 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 642B861533 for ; Mon, 2 May 2022 10:00:47 +0000 (UTC) X-FDA: 79420358934.26.F186B4C Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf08.hostedemail.com (Postfix) with ESMTP id 09D6316006C for ; Mon, 2 May 2022 10:00:37 +0000 (UTC) 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 33C57210E5; Mon, 2 May 2022 10:00:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1651485645; h=from:from:reply-to: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; bh=iTKK1xDtnmXAYeBi+dPbi8yteaHw0P2nDeN1SBWNaj0=; b=MgkEFVOILNEsJGU7lV+W1Duv+D56s8qcIPD4uiurhbUaI/fFhxuJSLbeXuUPNPmp3T3LwB R8LwQ+czdbKNkckdwJ54YxfupZX0dszqy2x2mwyobcMoRGhMdLOwgVeXLBw9NYfsakApZx MF9gYw0I7LGB3sNLonS1iTGeVvrNLko= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1651485645; h=from:from:reply-to: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; bh=iTKK1xDtnmXAYeBi+dPbi8yteaHw0P2nDeN1SBWNaj0=; b=Nj3KJAWkFC19kauBWwlkVq6mk+bTmGIo7dy42UvYuLm4H1AizBwqdlXYcPuTlnjyD92aF5 MrexEt86CBj5ENCA== 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 10CF513491; Mon, 2 May 2022 10:00:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id xXQUA82rb2J9NgAAMHmgww (envelope-from ); Mon, 02 May 2022 10:00:45 +0000 Message-ID: <49b0d611-e116-c78d-cf14-6d5f96ae500e@suse.cz> Date: Mon, 2 May 2022 12:00:44 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Content-Language: en-US To: Wonhyuk Yang , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , Roman Gushchin Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20220430002555.3881-1-vvghjk1234@gmail.com> From: Vlastimil Babka Subject: Re: [Patch v3] mm/slub: Remove repeated action in calculate_order() In-Reply-To: <20220430002555.3881-1-vvghjk1234@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 09D6316006C X-Stat-Signature: ewhdyofq1kehsiadecghx1ex8wa6qrsc X-Rspam-User: Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=MgkEFVOI; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Nj3KJAWk; spf=pass (imf08.hostedemail.com: domain of vbabka@suse.cz designates 195.135.220.28 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none X-HE-Tag: 1651485637-286368 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 4/30/22 02:25, Wonhyuk Yang wrote: > To calculate order, calc_slab_order() is called repeatly changing the > fract_leftover. Thus, the branch which is not dependent on > fract_leftover is executed repeatly. So make it run only once. > > Plus, when min_object reached to 1, we set fract_leftover to 1. In > this case, we can calculate order by max(slub_min_order, > get_order(size)) instead of calling calc_slab_order(). > > No functional impact expected. > > Signed-off-by: Wonhyuk Yang > Reviewed-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> > --- > > mm/slub.c | 18 +++++++----------- > 1 file changed, 7 insertions(+), 11 deletions(-) > > diff --git a/mm/slub.c b/mm/slub.c > index ed5c2c03a47a..1fe4d62b72b8 100644 > --- a/mm/slub.c > +++ b/mm/slub.c > @@ -3795,9 +3795,6 @@ static inline unsigned int calc_slab_order(unsigned int size, > unsigned int min_order = slub_min_order; > unsigned int order; > > - if (order_objects(min_order, size) > MAX_OBJS_PER_PAGE) > - return get_order(size * MAX_OBJS_PER_PAGE) - 1; > - > for (order = max(min_order, (unsigned int)get_order(min_objects * size)); > order <= max_order; order++) { > > @@ -3820,6 +3817,11 @@ static inline int calculate_order(unsigned int size) > unsigned int max_objects; > unsigned int nr_cpus; > > + if (unlikely(order_objects(slub_min_order, size) > MAX_OBJS_PER_PAGE)) { > + order = get_order(size * MAX_OBJS_PER_PAGE) - 1; > + goto out; > + } Hm interestingly, both before and after your patch, MAX_OBJS_PER_PAGE might be theoretically overflowed not by slub_min_order, but then with higher orders. Seems to be prevented only as a side-effect of fragmentation close to none, thus higher orders not attempted. Would be maybe less confusing to check that explicitly. Even if that's wasteful, but this is not really perf critical code. > + > /* > * Attempt to find best configuration for a slab. This > * works by first attempting to generate a layout with > @@ -3865,14 +3867,8 @@ static inline int calculate_order(unsigned int size) > * We were unable to place multiple objects in a slab. Now > * lets see if we can place a single object there. > */ > - order = calc_slab_order(size, 1, slub_max_order, 1); > - if (order <= slub_max_order) > - return order; > - > - /* > - * Doh this slab cannot be placed using slub_max_order. > - */ > - order = calc_slab_order(size, 1, MAX_ORDER, 1); > + order = max_t(unsigned int, slub_min_order, get_order(size)); If we failed to assign order above, then AFAICS it means even slub_min_order will not give us more than 1 object per slub. Thus it doesn't make sense to use it in a max() formula, and we can just se get_order(), no? > +out: > if (order < MAX_ORDER) > return order; > return -ENOSYS;