From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 453ACBA3F; Wed, 5 Nov 2025 12:46:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762346767; cv=none; b=rBq2INd0FzAFYO/9Njllk8CLTbkI/AFsl8hYM2q9EfgfeYh7nzDWN7vuJtxzWOMXhFw8fj6pouW7XI87pFgxOqaFaicJ14r9Ta/yR5a6ZHxswB+OlB+bTtzjBk21vCvpELH89uoN6rFEJibze8lwyx/rhVSc5rGldYVGVU7woDs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762346767; c=relaxed/simple; bh=BvDEj56XAXsDodkx5Q02Yxf+Bi9/3xVLnsDizWqbYsc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=jOB/hiPFjZMOeK0VaVyn0Qn8t5SMHo8o213JxP6NlsenRd41IbIQakkhwITdzHkaTyARficeMN+ves+r716BGaFBVcLCbFbj6uu5o9Fx/vy20ch3ygj2yM2gSFct9Ko/V6yghYI3BqNnLSvWr5Qn8MaCF3VAWo1rowiE7/7XL+c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=SeBik6wo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="SeBik6wo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A8321C4CEFB; Wed, 5 Nov 2025 12:46:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762346766; bh=BvDEj56XAXsDodkx5Q02Yxf+Bi9/3xVLnsDizWqbYsc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=SeBik6woaFJ+bXX3qvAsU4XjVrK1txJelzrGr66pJraD9/0mmqMzYnnX7e0QliwMx js6/DJ58gIhVGx5SupL3rZc2EiPCjFO4w0HdQFEoZioygXloAHZRRO+CqZGcoF76QG NHcyBp8ne3cwzFVBDlF5a2+IChS9yB4t9hg/RXV33D2FS+J1nVGJENQX/J9HlKEjjZ mT/mPhqKcHZQrfJa3VAE7Hrcbubizvq5m5jUt2TqBq/X7/bk+QNTVVrdXAUNeXrx28 N5F5TqMLWLFrOQhNenLYtcgmQ3c+qLOgyH+hszMeSgUl34WSYhYMSEacMIeKa0D9Qa 14dQ9+DPch2Eg== From: Andreas Hindborg To: Lyude Paul , rust-for-linux@vger.kernel.org, Thomas Gleixner , Boqun Feng , linux-kernel@vger.kernel.org, Daniel Almeida Cc: Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long , Miguel Ojeda , Alex Gaynor , Gary Guo , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , Benno Lossin , Alice Ryhl , Trevor Gross , Danilo Krummrich Subject: Re: [PATCH v13 11/17] rust: sync: lock: Add `Backend::BackendInContext` In-Reply-To: <20251013155205.2004838-12-lyude@redhat.com> References: <20251013155205.2004838-1-lyude@redhat.com> <20251013155205.2004838-12-lyude@redhat.com> Date: Wed, 05 Nov 2025 13:45:44 +0100 Message-ID: <87wm447imf.fsf@t14s.mail-host-address-is-not-set> Precedence: bulk X-Mailing-List: rust-for-linux@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Lyude Paul writes: > From: Boqun Feng > > `SpinLock`'s backend can be used for `SpinLockIrq`, if the interrupts are > disabled. And it actually provides performance gains since interrupts are > not needed to be disabled anymore. So add `Backend::BackendInContext` to > describe the case where one backend can be used for another. Use it to > implement the `lock_with()` so that `SpinLockIrq` can avoid disabling > interrupts by using `SpinLock`'s backend. > > Signed-off-by: Boqun Feng > Co-developed-by: Lyude Paul > Signed-off-by: Lyude Paul I am not convinced this makes sense. This saves us only a few instructions. We already have a counter on C side, so we are not going to update the interrupt control register if we don't need to. I'd like to see a micro benchmark showcasing the gains that we get from this complexity. Best regards, Andreas Hindborg