Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1928947pxb; Fri, 5 Feb 2021 05:13:35 -0800 (PST) X-Google-Smtp-Source: ABdhPJz371LPxL30/qloitJuef8RS5+v66mD4/qFX9SYuLLaHQh41pQqOYiU+V1WFp8o9/Fd1v7w X-Received: by 2002:aa7:d98a:: with SMTP id u10mr3423408eds.275.1612530814913; Fri, 05 Feb 2021 05:13:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612530814; cv=none; d=google.com; s=arc-20160816; b=NS4UCcEgimqx6NQ7OgPrGR83EttsmDrClqQnJFUrIUzmytw4n/vRZq4QU+k6T5d5FF OEd2Zl0rUBLgPK0s718xPR3ZqGp4jFdv/piL/BJKqPjPL2ulKACNxpxAnXV5u5sNxk+M rRA9KSJeiJaJnjFuOeHH5UZ207YFZ0EP4ty4baMKX8+3MNlXrU3ZhojB6LUnP6kqcVix 7xfvfj3Mu0SnnMsgfErGBiEc7MODNoWJRlx5BvOHawfHSXVqCCvSeGCDncqJHLdRE9Pz TjW8omg0B7nIVwxTfhtGQLwM/HVkZt07lmkjPcw++71cPgLJ6n8BycyLZ2PoPAwJmQyk f3iw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=ZDL+wOaLYignz9E4o4YNWRc3R6Y2n1RD6jLKjWfbB5w=; b=hsptR9BDdm5lTmOv7VVSslIx+jr9a/VheckcXd3cS1D7lFYhTxv7CjWoe2foc/s0VG nbag0nJdkiObjoFV5QeIeT1OQh/l54gDb/V0AT3N3QNKdtcskN/2ATnrcV7YXghItlmG IfjIZ+PFDU7MKT6b6WPOF5oTx9oquiDGCe4CSk5G/HVtSfB3l8zG4RJw6lJy8mZihko8 Wt4ddISUPFfIDKfASsxhwJXIe+BBXKUYNLc/9shnIoOblrGlfJ0p1vCeNGeeaFcsrGjM hQoTnncaPg8e+TVbcEAy83vptWfTKHpzRgoiMwwe7tJQZiDxolQ1ZUyhkFGzJf99w3m7 qevw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id jz7si2118141ejb.476.2021.02.05.05.13.09; Fri, 05 Feb 2021 05:13:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229586AbhBENJC (ORCPT + 99 others); Fri, 5 Feb 2021 08:09:02 -0500 Received: from mx2.suse.de ([195.135.220.15]:41872 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232080AbhBENFN (ORCPT ); Fri, 5 Feb 2021 08:05:13 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0FCAEACD4; Fri, 5 Feb 2021 13:03:58 +0000 (UTC) Subject: Re: [PATCH] mm/slub: embed __slab_alloc to its caller To: Abel Wu , Christoph Lameter Cc: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , hewenliang4@huawei.com, wuyun.wu@huawei.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20210202080515.2689-1-abel.w@icloud.com> <9A811B32-6E3D-4FE1-98A5-A7922C32CDB4@icloud.com> From: Vlastimil Babka Message-ID: <30743bfa-fbbb-c091-3b6e-dc24975fc6c3@suse.cz> Date: Fri, 5 Feb 2021 14:03:57 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <9A811B32-6E3D-4FE1-98A5-A7922C32CDB4@icloud.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2/3/21 2:41 AM, Abel Wu wrote: >> On Feb 2, 2021, at 6:11 PM, Christoph Lameter wrote: >> >> On Tue, 2 Feb 2021, Abel Wu wrote: >> >>> Since slab_alloc_node() is the only caller of __slab_alloc(), embed >>> __slab_alloc() to its caller to save function call overhead. This >>> will also expand the caller's code block size a bit, but hackbench >>> tests on both host and guest didn't show a difference w/ or w/o >>> this patch. >> >> slab_alloc_node is an always_inline function. It is intentional that only >> the fast path was inlined and not the slow path. > > Oh I got it. Thanks for your excellent explanation. BTW, there's a script in the Linux source to nicely see the effect of such changes: ./scripts/bloat-o-meter slub.o.before mm/slub.o add/remove: 0/1 grow/shrink: 9/0 up/down: 1660/-1130 (530) Function old new delta __slab_alloc 127 1130 +1003 __kmalloc_track_caller 877 965 +88 __kmalloc 878 966 +88 kmem_cache_alloc 778 862 +84 __kmalloc_node_track_caller 996 1080 +84 kmem_cache_alloc_node_trace 813 896 +83 kmem_cache_alloc_node 800 881 +81 kmem_cache_alloc_trace 786 862 +76 __kmalloc_node 998 1071 +73 ___slab_alloc 1130 - -1130 Total: Before=57782, After=58312, chg +0.92% And yeah, bloating all the entry points wouldn't be nice. Thanks, Vlastimil