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 07E37C46CD2 for ; Tue, 30 Jan 2024 11:05:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61D6A6B007B; Tue, 30 Jan 2024 06:05:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CD9F6B007D; Tue, 30 Jan 2024 06:05:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46E636B0081; Tue, 30 Jan 2024 06:05:02 -0500 (EST) 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 34B326B007B for ; Tue, 30 Jan 2024 06:05:02 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id F405E1A066F for ; Tue, 30 Jan 2024 11:05:01 +0000 (UTC) X-FDA: 81735695202.25.AB697EC Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf19.hostedemail.com (Postfix) with ESMTP id 709E81A0002 for ; Tue, 30 Jan 2024 11:04:59 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=upl+k7v2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=bA274UEq; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=upl+k7v2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=bA274UEq; dmarc=none; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 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=1706612699; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=UKC3VT/yxm8QuquH0mJbFZHi45tefg50JMHGoP/3fP8=; b=ubot4JkrRiRibXNDk1UKyEEy1ela+QHoS9azmJMtj8/8SKywr0gwwAlytat2OvT6y/vaOv hfD6jvF7COkWH3V/aWuJ0RWdwXtth/2tTj2EnoLPYMnVQRYMw8uafh4T9mPE9j+eBgyOFm 6O1ZLIHvUMDPX897vomdJLHsbLJcKDg= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=upl+k7v2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=bA274UEq; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=upl+k7v2; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=bA274UEq; dmarc=none; spf=pass (imf19.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706612699; a=rsa-sha256; cv=none; b=GZ0mJ/5JoeIdFYSMP76NHVjJ0l0tKMJuzMxYC7dJuw20M+6O5xYf9o7yK826mlZALUI6fO c9GKXuDduhK+IUPrZ7DUvL8HeFV1sX/CRUsFDU2VHpl9y80h50wkYBfHiw5lIvxTvAwfrg 9edbkdRHiH4yjmqTA/3jT/mzq3CXsT4= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 98AFC1F842; Tue, 30 Jan 2024 11:04:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1706612697; 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=UKC3VT/yxm8QuquH0mJbFZHi45tefg50JMHGoP/3fP8=; b=upl+k7v2jgC8e/LOcqed3oJ7nMEKZZwBBVVFePzAUZivut0SOR3ayyCUaQEkqeOtEU2wlN EBECpioeOmWyyQ9aYCJ1GVRZDjTtNrEhDbND7YGNXMzI1rFjXrKUwRXZDhIbx8XMzjYOOU FJ3AJS2RJq+ToBlBmw7fxgdaMHJy/SI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1706612697; 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=UKC3VT/yxm8QuquH0mJbFZHi45tefg50JMHGoP/3fP8=; b=bA274UEqLWuoPqTyOiMkMod8zh206bkz2t3SI/Lg/j24OKwKuIzwxprbxrwonjFXWwe5qr bOS/gUc8alVD1JCA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1706612697; 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=UKC3VT/yxm8QuquH0mJbFZHi45tefg50JMHGoP/3fP8=; b=upl+k7v2jgC8e/LOcqed3oJ7nMEKZZwBBVVFePzAUZivut0SOR3ayyCUaQEkqeOtEU2wlN EBECpioeOmWyyQ9aYCJ1GVRZDjTtNrEhDbND7YGNXMzI1rFjXrKUwRXZDhIbx8XMzjYOOU FJ3AJS2RJq+ToBlBmw7fxgdaMHJy/SI= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1706612697; 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=UKC3VT/yxm8QuquH0mJbFZHi45tefg50JMHGoP/3fP8=; b=bA274UEqLWuoPqTyOiMkMod8zh206bkz2t3SI/Lg/j24OKwKuIzwxprbxrwonjFXWwe5qr bOS/gUc8alVD1JCA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 6F88012FF7; Tue, 30 Jan 2024 11:04:57 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id pETmGtnXuGVMPQAAD6G6ig (envelope-from ); Tue, 30 Jan 2024 11:04:57 +0000 Message-ID: <8fc59462-2940-4e60-95f1-2955a8c24ea0@suse.cz> Date: Tue, 30 Jan 2024 12:04:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RFC 1/4] fs/locks: Fix file lock cache accounting, again From: Vlastimil Babka To: Linus Torvalds , Shakeel Butt Cc: Roman Gushchin , Josh Poimboeuf , Jeff Layton , Chuck Lever , Johannes Weiner , Michal Hocko , linux-kernel@vger.kernel.org, Jens Axboe , Tejun Heo , Vasily Averin , Michal Koutny , Waiman Long , Muchun Song , Jiri Kosina , cgroups@vger.kernel.org, linux-mm@kvack.org, Howard McLauchlan , bpf References: <6667b799702e1815bd4e4f7744eddbc0bd042bb7.camel@kernel.org> <20240117193915.urwueineol7p4hg7@treble> <6d5bb852-8703-4abf-a52b-90816bccbd7f@suse.cz> Content-Language: en-US In-Reply-To: <6d5bb852-8703-4abf-a52b-90816bccbd7f@suse.cz> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 709E81A0002 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: km5uqpe51ueqkibzm8ede76kargn8hzo X-HE-Tag: 1706612699-199339 X-HE-Meta: U2FsdGVkX1+x/nnq7hjXiiZfX7o67wz5+XfAKN4X3G0FsKNr+PlgdploISwZYYGHuAAsYlteNioBWv6nyRkofFZtJCiITtASKgtPqXhDdrPxWuLAZWovkehtjifd3gCzMxF6H4e9OZMmOusziYDDkwb9ABnGAN4Y0Q4yg0pYCepUUlLRlRv3QemnBbKoA4P77LXuVZWzTeQa9jCVvLRicwSBoBUoVDydHznRPqpnr1C1IkO4pIyPMdC/u05kVYL3fj9gd2JiktJFQi/N0Y1ugI78mK4yvP+Kq/mMAMZGnnT1dzaGWLacNtDLcmh0ZGwWnFdvQ2z3NAwlQfRTxfnpbMrKv/o8qC50BQ1Ne/r9MtTrdSw5GOwXyRU5GFd/p8syAZM3VrgYWKLsu+lG7/v5+5w/kEAvHO6VQZqZOXnNnWPWvceDEE3/WlqY4hRMyyn4uGY4rZ1Ap9TqgNWtAmxNKaSmaGKn9tn1NNOfFlULBwf753R+59Hy63bKyrANVz3qTfhrhM4uM2VX8/jbHVkQVEOibH/TZHMFAJkLOAoAVdj7h9NW0lnaZ1ORePxyY8eZ58o1sNy6Pa29jfF4DVNGfGn80JN3T3r1+cC7o+oTHq8ETVwxnZxxhWnuSKGt0ZdzzdL5yBiMZ1wjmpZ1TGP3Zh4UWxveIIXrZJWW/KpQoJUZjXuMRtDvI+aYx7yrA/8hLWONm8ipJ0qx3FTQ2CtzH7f+03k4zK8x+7wEWUDQpBl+GTr0509ARpO30fxSI+VGxD5rI+YkqdOckwCwDu+koPv2Q9dSVSiKBaeu/d8qjZTLv64vwC8YGjlACKo5sc5R6FaajtPh7DU87YNiAPafszVFabGDAhIWoEUX5sSbaTHFMYzzu1KVD+Zv//5X7FGrQA/7mSyJAwE5RBV2/dGUHun8JwHg036LXgtArEvYsuP02s+314BskAsY1FjfTr1jdqI5I8AxId/TqZ1O/pd 71uohDqP Ds8giEOnJf6b3av02kVa0WLzLKAYzsNoTRXb8tv05Q0a0nyAN/JJW9qKKUfC+D9Im33QqtO+JhmB3AQJKyYNyR13Az8HYLItEYtYg24sEWdRs+W5t9rfZ7ZRDXSzzqv/g84wrTurnys2Yc+WaIkPVHOi+8lUhyPY7H2MUU4kPvC7lAm1e4zK9jm4vw9Zw72J+CcrA3PeLiCutDvtLnpQ608RMZP/GZ1ShEkmzUjmbgn0xK/MuNzHNU9lsjOvSDPNZFnc6J0sqCz7WpB76VRIfU4yKdM0NfIS/ntTJfPyCT5N4FThfQyS20C4e9jSZehduz0i0nwlTvcwIZPGsLtr8wiu+s5tKkd6KGgUTqjCPwO/SoMc4o0Uszt0z2w== 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 1/26/24 10:50, Vlastimil Babka wrote: > On 1/22/24 06:10, Linus Torvalds wrote: >> On Wed, 17 Jan 2024 at 14:56, Shakeel Butt wrote: >>> > >>> > So I don't see how we can make it really cheap (say, less than 5% overhead) >>> > without caching pre-accounted objects. >>> >>> Maybe this is what we want. Now we are down to just SLUB, maybe such >>> caching of pre-accounted objects can be in SLUB layer and we can >>> decide to keep this caching per-kmem-cache opt-in or always on. >> >> So it turns out that we have another case of SLAB_ACCOUNT being quite >> a big expense, and it's actually the normal - but failed - open() or >> execve() case. >> >> See the thread at >> >> https://lore.kernel.org/all/CAHk-=whw936qzDLBQdUz-He5WK_0fRSWwKAjtbVsMGfX70Nf_Q@mail.gmail.com/ >> >> and to see the effect in profiles, you can use this EXTREMELY stupid >> test program: >> >> #include >> >> int main(int argc, char **argv) >> { >> for (int i = 0; i < 10000000; i++) >> open("nonexistent", O_RDONLY); >> } > > This reminded me I can see should_failslab() in the profiles (1.43% plus the > overhead in its caller) even if it does nothing at all, and it's completely > unconditional since commit 4f6923fbb352 ("mm: make should_failslab always > available for fault injection"). > > We discussed it briefly when Jens tried to change it in [1] to depend on > CONFIG_FAILSLAB again. But now I think it should be even possible to leave > it always available, but behind a static key. BPF or whoever else uses these > error injection hooks would have to track how many users of them are active > and manage the static key accordingly. Then it could be always available, > but have no overhead when there's no active user? Other similars hooks could > benefit from such an approach too? > > [1] > https://lore.kernel.org/all/e01e5e40-692a-519c-4cba-e3331f173c82@kernel.dk/#t Just for completeness, with the hunk below I've seen some 2% improvement on the test program from Linus. Of course something needs to operate the static key and I'm not familiar enough with bpf and related machinery whether it's tracking users of the injection points already where the static key toggling could be hooked. diff --git a/mm/slub.c b/mm/slub.c index 2ef88bbf56a3..da07b358d092 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -3750,6 +3750,8 @@ noinline int should_failslab(struct kmem_cache *s, gfp_t gfpflags) } ALLOW_ERROR_INJECTION(should_failslab, ERRNO); +static DEFINE_STATIC_KEY_FALSE(failslab_enabled); + static __fastpath_inline struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s, struct list_lru *lru, @@ -3760,8 +3762,10 @@ struct kmem_cache *slab_pre_alloc_hook(struct kmem_cache *s, might_alloc(flags); - if (unlikely(should_failslab(s, flags))) - return NULL; + if (static_branch_unlikely(&failslab_enabled)) { + if (unlikely(should_failslab(s, flags))) + return NULL; + } if (unlikely(!memcg_slab_pre_alloc_hook(s, lru, objcgp, size, flags))) return NULL;