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 5799FC30658 for ; Tue, 2 Jul 2024 21:16:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C7EBC6B0082; Tue, 2 Jul 2024 17:16:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C080B6B0085; Tue, 2 Jul 2024 17:16:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A5A2B6B008C; Tue, 2 Jul 2024 17:16:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 842E46B0082 for ; Tue, 2 Jul 2024 17:16:00 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0932512059E for ; Tue, 2 Jul 2024 21:16:00 +0000 (UTC) X-FDA: 82296070080.17.9CE89DA Received: from mail-ed1-f47.google.com (mail-ed1-f47.google.com [209.85.208.47]) by imf06.hostedemail.com (Postfix) with ESMTP id 2F818180019 for ; Tue, 2 Jul 2024 21:15:57 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SMLAdSs3; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719954927; 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=PLK9aj4vFqWhZL5t10A0/zYFTcmHZM8OXrcD4U0TrDc=; b=rB9SNvVwYW2+RagA5E+6QD3sqeB8gRHSvdV2aGLLTnLYkJYvUndGlMK764FtCGecnjmJmk 1oKjL9g7thenqullzxP+8PcdkCWtc2QEqh3sqkCopNDKZkMVzVgy7NJ/ht3jeyy54C7I8K lOhQAP68IcIlszYtNk2aI732wRQMC2Q= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=SMLAdSs3; spf=pass (imf06.hostedemail.com: domain of mjguzik@gmail.com designates 209.85.208.47 as permitted sender) smtp.mailfrom=mjguzik@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719954927; a=rsa-sha256; cv=none; b=cExQuHbIyODa+Ewyi8IjnahnrKEnXv9o5Ppf9pjBbyflEzymzrBYFaPpOZj8pM/QpMuC6a AYHGRM1mHs0fstN7YYhQQEKtXcqY61SjEQmn9l+1oGbP4MSuJf7kQvSh+gK9B4l+Xf9Pzd F2hH61eLiflGonHn88T7vqyD0v1/I3I= Received: by mail-ed1-f47.google.com with SMTP id 4fb4d7f45d1cf-58c947a6692so307978a12.0 for ; Tue, 02 Jul 2024 14:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719954956; x=1720559756; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PLK9aj4vFqWhZL5t10A0/zYFTcmHZM8OXrcD4U0TrDc=; b=SMLAdSs3Gc3D7bzAXdTGIhGTjOFBev4mNxc81fScjbjrXE7Qcjr6+1oX9hCuzthJ5o fXUzJOn8C1FIlzwbj4MEVR/515z3Cknb02ZnARkAruXzu1Wwj3UiO26/Rphq9Hh+A5Y9 2GmRIdB50IMDM37GOGtUdlz61O4eGRrRksf3CbSOUEw9pP1MwDgRr6wh+vIHnue/4seT gU8Ti4f6KPg6iESHcQ0casuS4FMTjjG2WJdyUdLQsciZV2RVuIQuDY3sq5FPF02eN5N/ cJTvYsQ+JqhmXeVYKsLNE3aftzBMqYyDdl2O9SOzQcS267kZRCJL1xs2jZcGU/OjaLUl JF6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719954956; x=1720559756; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PLK9aj4vFqWhZL5t10A0/zYFTcmHZM8OXrcD4U0TrDc=; b=GiVpkPhC3WjOSPr/2s5d2oW8C1OA9MPZw+ALRLWGNkIBeQVRClEzSaBYAt/tUA4B/n 66EAEg46wJVhzrA+QIagXnpLIwIZzKhDIMo9pX0cjVrwssmc3wlGfcRKcszIqPt3DakX UzWqWFjueQr6wFiv1uJJUqQZipw4jpHLswF6uwaXt1lHVG+etGRJW4obP9Cr1iDCjjJv EE+gGE2kbU010QC/mHwfO+V4FOOw2uviVo7BASmmww/UIQGCPhFbnEwhmghazWWX5F+o PZVWxN5Z9Gcc5FcDqrcVhKgr+bhKnRn+cLB+h27E1U2cyfyEYczmcuu4dl456Crqw/+C 20Lw== X-Forwarded-Encrypted: i=1; AJvYcCXlU1eAc75J9yGAiW+bu1d3E0od72RhJicEkpdv6gaFYL/U0qwfz4V8kupTSpwtY5B9Tl94fOSwaaJQrjasdElUUAs= X-Gm-Message-State: AOJu0YzxV8qjmPtA5PzdPDDJhWN1YYWOMH7VY6xDSMUaTlgaMjtuZ6B0 OEDUp8/ZxM6X0oYoC3rnmO7Igu8RUgiMmPxTD/A4XHUjWzszXwHj X-Google-Smtp-Source: AGHT+IGCT4ZcS2hWBpqR73pLxAO1+F3bfc5uZOtzmRlNvQB2X8vmqHx3H6TNdYR0k2Aqy7zatnWdXg== X-Received: by 2002:a05:6402:354c:b0:57d:5c96:72aa with SMTP id 4fb4d7f45d1cf-5879be9a1a7mr7914346a12.0.1719954956486; Tue, 02 Jul 2024 14:15:56 -0700 (PDT) Received: from f (cst-prg-31-46.cust.vodafone.cz. [46.135.31.46]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-58614f3d415sm6196769a12.85.2024.07.02.14.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 02 Jul 2024 14:15:55 -0700 (PDT) Date: Tue, 2 Jul 2024 23:15:44 +0200 From: Mateusz Guzik To: Linus Torvalds Cc: Christian Brauner , kernel test robot , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , linux-kernel@vger.kernel.org, ying.huang@intel.com, feng.tang@intel.com, fengwei.yin@intel.com Subject: Re: [linux-next:master] [lockref] d042dae6ad: unixbench.throughput -33.7% regression Message-ID: <6knlkefvujkry65gx6636u6e7rivqrn5kqjovs4ctjg7xtzrmo@2zd4wjx6zcym> References: <3g3arsrwnyvv562v2rsfv2ms4ht4mk45vwdkvssxkrjhfjtpdz@umyx5tl2du7o> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2F818180019 X-Stat-Signature: f8x8bxre8c34g66gm9xjc9em1b5efbnp X-Rspam-User: X-HE-Tag: 1719954957-783215 X-HE-Meta: U2FsdGVkX1/ok09ynuPpJ9i5X5xraX5E9g7bGJ54igE7HAD+0JR2wvDQHv2ZZCAwtbK2wHaxAVVGN5uPoxqBttq9iewfmO8RzLqefYfZ0Fo30yvQKa2imhcBPTTYL8Il/koAgF4qcNvd3hset9E/aJuyHxEoYWWIIZVHLKyDiStm+d+ywYkEPrLhWE/ki3SyJdQ4FnUPya3Ip/iBI2tdHB8juKMwRparhTaSlZciVC1rHWPd6f1od/PZndq+LczCa+L+IyEer279aandp8msTDDUcmxVCnHBJof62/gCzHL7slCvievM1/A8MZ4xTF+VhEPnluxkICNQMitGq6OyHrHa7GmYKA5Bdc/i24j7zm6rT1Kw2Adrc1Vi0Ltvs0RlXJ4h0lU4oUdVHdm7ndOl50g+I5CQ11Cdf65SLkQvyy4Yglik8DYfZmCDXDLkN30ZhGr/JLBupp68UVUYIEHGqeLRWbVlVnQbO8rOg/tA9j+Wk+himRA+ITkwf6bcYi9s7XzIC4XFMcTtDL9Xu1Fvoic2l4aH2grckD5KguKd2pRtRQwgLKZ86VhacBShJ+9tm++mwgYNm1T2JCQpiuzvemBGD6UXpRESTsjipE17RrERi9RiZvUigYr1BaV9M3a0CNjcH4FbAcQBMGGHlIMNyMFJMX7i+FsXyzaxMRToEe6UCT7mQQgfG1LkULfk6yiXOxsl48+yC3YEk+IFHvK9LEL0qVaZtu6VgNIHARlqCwCP/p10nbJbf4UJ9PmRxDH1BkfKRwRG+POdRe1YHC6wa6ZMXdEkTAhJsFJZLdfCtg2pJnxwpHxayL73cksnydfzpDchctL7/uQ3Jkf73tTIKI8RV9HIHI/UwWN0ydbErDNhxHUA0ZgxH6cODz0Yc0dlPAkeBZvt3xM3Ie0ukHyTd+BrXnMMXiUvtaJ4xIw9yuG33LPNX12nX9ua3EYA5aOLZ2LstdxRsjnP/aqJyfq vXNmWQ9B Mu/qG8dcM8CblQClVDkoQkOHqniw/M+9uTxc+sZddXRUJxXxNYF7hibizq9jrBN+sbnnYOy4dgkSQNTINuIbA+KRg+tmZ58AnfDzD2rHrWxaMtVO3xd/PY6k0nfRkst2749GCMgLMWeCMVrJeAnlm8P3iUHzQgXrHsK44WPT+Z5ktBPP/X1Up0iDiiaYs4K5j8o3j0oMmYoMBrSBsHFQgS22jsTbd8ZLu6cnXICkEVittbjQsIquLh6jM25o0HnUFJFt5QMAMBGCQHkKRhzb8rQ6MDF5v1og0CIDX9BRvDXc1dqK7DXHjL41fRVx1jPua0LcQgHWJ8deKsGJvbaYfoGxCeN2vPEnyLXJRIbmI1TLNZQfZF62AXMfnXTlRdlTu0D0jvvhl4k5r/a7v8xM4SOFIlcKr3pMKHDzq2r8CDDlXHifxUAFHdF/LcRYS810XuiHUe8VVqHmpU20g68QRZtkBLjrj02t0Iz5o7oX5TkTxgOYlX9UDwm1ZWb8soPjBgGNu 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 Tue, Jul 02, 2024 at 01:42:48PM -0700, Linus Torvalds wrote: > On Tue, 2 Jul 2024 at 13:33, Mateusz Guzik wrote: > > > > If you are politely by lkml standards suggesting I should probably drop > > the idea due to unforseen complexities > > Oh, absolutely not. I'd love to see how nasty - or not nasty - the > patch would end up being. I think it would be very interesting. > > I'm just explaining why _I_ never got around to it. > ye I get it, but the above by me was a passing remark anyway :> I asked you something in the previous e-mail though (with some nastiness of the problem pointed out) concerning handling of slow vs fastpath, here it is again: [..]for example did you know xfs does not honor rcu grace periods when recycling inodes? https://lore.kernel.org/all/20231205113833.1187297-1-alexjlzheng@tencent.com/ So this would have to be opt-in per filesystem, probably stuffed somewhere within the inode or dentry. I am definitely not reviewing all the other filesystems for sanity on this front. Rather, one could look over tmpfs, ext4, btrfs and maybe ask Kent to sort out bcachefs (if necessary) and call it a day. Sounds like you are deadset on the callback approach. I'm not going to die on the inline hill, but I will spell it out so that we are on the same page (and I have a question too). In pseudo-code my stuff would like this (names are for ilustrative purposes): struct rcunameidata { .... bool in_rcu; }; ... struct rcunameidata *rnd; error = vfs_rcu_magic_lookup(&rnd, ....); if (error) return error; if (rnd->in_rcu) { /* * fast path goes here, callback code would be identical up to * the point below */ /* * Now validate */ error = vfs_rcu_magic_lookup_validate_or_drop(&rnd, ....)) if (error == 0) /* things worked out */ return export_stuff_to_the_user(....); if (error < 0) /* fail */ return error; } /* * slowpath goes here */ /* * all done, now whack the lookup state. the routine returns void */ vfs_rcu_magic_lookup_finish(&rnd, ....); if (!error) error = export_stuff_to_the_user(....); .... Can you pseudo-code how would the consumer look like in your case? Do you want the callback to execute for both slow and fastpath and switch on the flag? It is rather unclear what you are proposing here. fwiw I think the above would serve as an easy to copy-paste idiom for the few consumers which want it. All the complexity in their case is the in_rcu block which wont go away with a callback. If you still want the callback, callback it is.