From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f176.google.com (mail-qk1-f176.google.com [209.85.222.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BE06B1885A5 for ; Sat, 22 Nov 2025 03:35:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.176 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763782549; cv=none; b=RZh6FdIi7aVF7BgxQPetprzP4tKXu+iFjafbMEEafNEsJrVDJRgxMzQTJ/5nfXFjAog6ZzoW6Sh7otZnR12L/s5rOjgxbT/7zChInH3d+BoCozEMpsOkcxUB1+LxgHadZTTNSBFqFxJytPgzVq2dACMuvb3paE8StZoo1/o+mL0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763782549; c=relaxed/simple; bh=B5kQ91yQvSF3kgcWoMjPARGk6eFcPbswpLwglx0rhK8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mwQe3Lu7uNchftzS8Lxk9wQ4QpxOJZPb3dDQ9Isrr1XGR4RFgY39ZDhgYJ2Z4wOb2IfyDFGJli8B7f6PYJmCSVlWOFVoKKSkA+rge8A/ktI2jmWFXdLEoauDyQVFXEir4rLCGv3UhChjMvs0dODM/8KTNR1VIYHIM6L1KJr3Jo4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=GlPhuC4K; arc=none smtp.client-ip=209.85.222.176 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="GlPhuC4K" Received: by mail-qk1-f176.google.com with SMTP id af79cd13be357-8b2d6df99c5so397516485a.1 for ; Fri, 21 Nov 2025 19:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763782547; x=1764387347; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:from:to:cc:subject:date :message-id:reply-to; bh=jKcteihLZKJWkTLMA27RQMtx7kBlICGP8oyxfNV16xA=; b=GlPhuC4KAFJaQbxHQqlndJRwomfZWC17rkrytuurl4VyRhTjuKaIXnMq42/GXk/BY7 7rxTGFeTTlb7g0ZAtIjemULuXKCifeeo6kMfQLnYAWTTh0jPCvAlE72rLydzmAB51f0C lfyWxxULTA5J/6CRdlqWTO+iLnmtCofEPhYlFS9jCXMxCW9HP8wS3yWQEkq16Mq+JJiV EDkf01Xsm/WhWBhP04+5XVOb1KbhZWb9ytVFHuSL6O1EUvCdNyZpVASCqr+xDIjsTYle 4QxVydlj61Pm/+vrG6KqhPXP1S0dauZ2SaJjK7Q+TqwjnyDC0FlI9nhYgFgh4bhLsFAx GBRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763782547; x=1764387347; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:feedback-id:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=jKcteihLZKJWkTLMA27RQMtx7kBlICGP8oyxfNV16xA=; b=wqO0HAOsnESmWMN8jyBo0IU2mj37ybfibkPkH7o2Orzl3LGddwcwLk+y2ccuxh9D7j 9LMXpHASjAKLp7m7ACJgYKdiVeSGuOIo5AOo9vNVBSvOOPMk/BdJpNVy0DA6obXtHDz7 9y1uXDffewfMtEt2eVZiWNb5K7z5igX81piWUm00dgyoVGKfF/q4vyRAvl/HfLlkEac1 zKiD+japtF7/zW4aymhkFW0q7Syp/MRQ16G1kUaC6TLRT3vHBZ14/e6K7qgNYht7iyhA 4ojScRzGhzVhZfvtyfcaB072/O1W7JEc0DvcxFKRpzfBmV/EwoKeDSTF3M8X4pIPsFls i0lw== X-Forwarded-Encrypted: i=1; AJvYcCUm+BV9OENhspKiHnWzNh06+gI2ANHILHfEdprCQjt2BLxi+Ds3e1VfKPajCUasJtz4R5ClKuj/srctHpM=@vger.kernel.org X-Gm-Message-State: AOJu0YwNkOtplLg/l4TKQK8UoPgiUoW0Vy7ZN0q8pXpWEiRra9rq8I7W vvym5nfQqUOeeeVIYPdD0KBFzFy04Pj7RiwIjI7FVJBCCmXFEsNPCN62 X-Gm-Gg: ASbGncurHWH67Lsp+Nq+04IVNZJdXlAIPYBOtXSwYY41Ny+FWOGgZQWTIDJaNDXVyww IwNyQAHyh5CbNX5YfBk8YxG/lrnsOHluzmhFQfqkrsp1Z2qz5zKpzb6j4kMC59bD4SXPj2Sgh8w q1tIfhyoaX4fhKjvRGhX87+oH+FL7czV5ttrdMHBdjxolmRNDC46BZeT4OZAF8rDbReB1KaHCbB xPFu+pRTi1tFI+Zxc1+WosC/a4llFo6Ch5TjSwmonDS7uTulx0eLAB29AZoCRjFiHz8YQYfeTw+ P+nHT9xqHFkMNLSxK2Ju2P9Eg5cvBNLsTZMWAI4L94yBFaq/Mv46IGAhxmlm9AyoKMx7gi9q75d wOaQTJQ9NtLshtPLMKURO/tlzHmTdbkfNk1nqfVq+HG9MpcGFqy1uMzT5kUSSfWSe5SoqTIGJ3H Hh96dk2ZXUr6ZLox9kWiGius20ez20U6QbmviqgQ7aWEB5XMh7rDKB7cs+kFOyMk7Vyoqc8wJwD +SauVcaWc8HohI= X-Google-Smtp-Source: AGHT+IFBIpfjoyt0q1w8Vqzk831RHkJ/1JMTzIuFlxWmEdwt79pYpHGGnqIJ/yW6L7eD8uEFixb5ew== X-Received: by 2002:a05:620a:318b:b0:8a9:eb31:1033 with SMTP id af79cd13be357-8b33bde837cmr780815585a.30.1763782546617; Fri, 21 Nov 2025 19:35:46 -0800 (PST) Received: from fauth-a1-smtp.messagingengine.com (fauth-a1-smtp.messagingengine.com. [103.168.172.200]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8b3295d94b6sm480106285a.36.2025.11.21.19.35.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 21 Nov 2025 19:35:46 -0800 (PST) Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.phl.internal (Postfix) with ESMTP id 5E0D3F40079; Fri, 21 Nov 2025 22:35:45 -0500 (EST) Received: from phl-mailfrontend-02 ([10.202.2.163]) by phl-compute-03.internal (MEProxy); Fri, 21 Nov 2025 22:35:45 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvfedujeekucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunhdrfhgvnhhgsehgmhgrihhlrdgtohhmqeenucggtffrrghtth gvrhhnpefhtedvgfdtueekvdekieetieetjeeihedvteehuddujedvkedtkeefgedvvdeh tdenucffohhmrghinhepkhgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghuthhhphgv rhhsohhnrghlihhthidqieelvdeghedtieegqddujeejkeehheehvddqsghoqhhunhdrfh gvnhhgpeepghhmrghilhdrtghomhesfhhigihmvgdrnhgrmhgvpdhnsggprhgtphhtthho pedvuddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepjhhhuhgssggrrhgusehnvh hiughirgdrtghomhdprhgtphhtthhopehlhihuuggvsehrvgguhhgrthdrtghomhdprhgt phhtthhopehruhhsthdqfhhorhdqlhhinhhugiesvhhgvghrrdhkvghrnhgvlhdrohhrgh dprhgtphhtthhopehlihhnuhigqdhkvghrnhgvlhesvhhgvghrrdhkvghrnhgvlhdrohhr ghdprhgtphhtthhopehtghhlgieslhhinhhuthhrohhnihigrdguvgdprhgtphhtthhope gurghnihgvlhdrrghlmhgvihgurgestgholhhlrggsohhrrgdrtghomhdprhgtphhtthho pehojhgvuggrsehkvghrnhgvlhdrohhrghdprhgtphhtthhopegrlhgvgidrghgrhihnoh hrsehgmhgrihhlrdgtohhmpdhrtghpthhtohepghgrrhihsehgrghrhihguhhordhnvght X-ME-Proxy: Feedback-ID: iad51458e:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 21 Nov 2025 22:35:44 -0500 (EST) Date: Fri, 21 Nov 2025 19:35:43 -0800 From: Boqun Feng To: John Hubbard Cc: Lyude Paul , rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, Thomas Gleixner , Daniel Almeida , Miguel Ojeda , Alex Gaynor , Gary Guo , =?iso-8859-1?Q?Bj=F6rn?= Roy Baron , Benno Lossin , Andreas Hindborg , Alice Ryhl , Trevor Gross , Danilo Krummrich , Andrew Morton , Peter Zijlstra , Ingo Molnar , Will Deacon , Waiman Long Subject: Re: [PATCH v14 00/16] Refcounted interrupts, SpinLockIrq for rust Message-ID: References: <20251120214616.14386-1-lyude@redhat.com> <4b6ae41e-5cda-41ab-ba4e-628bdf23f917@nvidia.com> <49d7b2c0-9794-4997-8bba-78891f27abf0@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Nov 21, 2025 at 06:56:28PM -0800, John Hubbard wrote: > On 11/21/25 6:38 PM, Boqun Feng wrote: [...] > > > > Last but not least, safe Rust is preferred, but it doesn't mean unsafe > > code should be avoided completely, if we establish some data that shows > > Perhaps we need to be slightly more precise. I'm not sure if you are > referring to the usual practice of creating an unsafe block, wrapped > within a safe Rust function, or something else? > I was referring to providing an unsafe API for core kernel functionality, for example local_irq_disable(), and then teaching how to use it correctly. > > some unsafe code provides better performance and we have clear guideline > > for the particular scenarios, then it's definitely OK. Hence I don't > > fully agree your saying "Safe Rust is the whole point of this project", > > to me understanding how we can utilize the type system and other tools > > is more of a realistic goal. > > > >> Is 3.6x longer really something we are stuck with? Or is there some other > >> way forward that could potentially provide higher performance, for Safe > >> Rust? > >> > > > > Well by 3.6x longer, you mean ~1.3ns vs ~4.5ns, right? And in real world > > code, the code in the interrupt disabling critical section would be more > > than couples of nano seconds, hence the delta will probably be > > noise-out. But again, yes if 3ns turns out to be a bottleneck in the > > driver, we are happy to look into, but you need to show the data. > > > > So this is what I'm asking about: given that we *already know* that we > have a performance drop in the micro-benchmark, is there any reasonable > approach that avoids this? Or has a less noticeable impact? > Lyude had tried another approach [1], which uses an unsafe public API, and doesn't work (easily) with CondVar or PREEMPT_RT And that eventually triggered more discussion about a better API design, and as Thomas pointed out [2]: "Stop worrying about mostly irrelevant low level details which are not relevant to the primary audience of rust adoption. We can worry about them when we replace the scheduler and the low level interrupt handling code ten years down the road." And I agreed. The current implementation is actually quite efficient and should even out-perform the existing API in some cases as I pointed out. More importantly, it utilizes Rust type system and make it easy to use (or hard to mis-use). That being said, if anyone has a better idea, feel free to bring it up. > I'm asking early (see above: I agree that this is "premature"), because > we have early data. > > It would be nice to explore now, rather than later, after someone shows > up with detailed perf data about their use case. > > Not sure I fully agree with this, given it's to my knowledge the best solution at the moment, I feel it's hard to justify the cost of exploring a better solution without a real usage. But then again, if anyone has any better idea feel free to bring it up. [1]: https://lore.kernel.org/rust-for-linux/20240916213025.477225-2-lyude@redhat.com/ [2]: https://lore.kernel.org/rust-for-linux/87iktrahld.ffs@tglx/ Regards, Boqun > thanks, > -- > John Hubbard