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 1E67A366043 for ; Wed, 4 Mar 2026 16:29:15 +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=1772641755; cv=none; b=swX9uM7qmwUZ96RmJBA95vepXlupbWl+pZ3aLEN0U7+/Wmps8g+wudYP7rnm0kwW3m+kl/et5rgTgmhel8SP77AZ0u+7ZrqAcfejW6aH4H+JaIvOHAftR3Kzca0bah6IXQhTYTKh4ZCG3dqm4708QK654lzTqsF6wOl3TKn30Q8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772641755; c=relaxed/simple; bh=03B2sII/wLyEEQmGcMTzXqixo/P52R1q/pDe72u3uUI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=cPPqUeJ5ppkuLrEp+rgU1s6EFecX3f4JkWIACPFkoC+q6F/1vPqojkg2TscB2E6JF9vXVi8IRveCOXHSl+goUFnEUqgZqaXiwBe4JLE4IwseuTSumhgem2y2SrKhvyUZo/HBpbYHXB6MUOnZHCSR564Huc85wlbD6yTVX70pbs0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=U7I/aSaZ; 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="U7I/aSaZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8106AC2BC87; Wed, 4 Mar 2026 16:29:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1772641754; bh=03B2sII/wLyEEQmGcMTzXqixo/P52R1q/pDe72u3uUI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=U7I/aSaZjksmqdFsuoGPl7phg5SnEmDx59qYo9qSqetn0Onnr3hwW2W39/KDSPU6I 43PAeMfRQFt1Y4X9g+u2ek0UpY5jSKt2CkjMcnA/IxREETPMaPlGGWO00ttINnxvs3 qiky8hF9gm9qhqHB2O7SLbEEkPkM9+TPcWgf65WK2Qr3SXaTfZBLH5B3W3Ht+UOrYT khjHt3r1bwcuSK08FzEeAHrQt7ymoWKNtirfOU26cySiIZYTRqL2dUVkTU1W89rfGp KvhiOrkP6CJJRs5VBTTwUHtcSB+6EAoRFhoCSOcp5uYLYNP3tqMmNTX+f/p+4YjZBH G4IRJKZMN5tfw== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.phl.internal (Postfix) with ESMTP id A18D3F4006C; Wed, 4 Mar 2026 11:29:13 -0500 (EST) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 04 Mar 2026 11:29:13 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvieefleejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepuehoqhhunhcu hfgvnhhguceosghoqhhunheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtthgvrhhnpe eifeeuleefudevleevhfehkeffuedttdetjeetgfejtdejfeeltdekhfevleelheenucff ohhmrghinhepfigrihhtpghquhgvuhgvpghhvggrugdrshhonecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghoqhhunhdomhgvshhmthhprghu thhhphgvrhhsohhnrghlihhthidqudeijedtleekgeejuddqudejjeekheehhedvqdgsoh hquhhnpeepkhgvrhhnvghlrdhorhhgsehfihigmhgvrdhnrghmvgdpnhgspghrtghpthht ohepuddupdhmohguvgepshhmthhpohhuthdprhgtphhtthhopegrlhhitggvrhihhhhlse hgohhoghhlvgdrtghomhdprhgtphhtthhopegsrhgruhhnvghrsehkvghrnhgvlhdrohhr ghdprhgtphhtthhopegsohhquhhnrdhfvghnghesghhmrghilhdrtghomhdprhgtphhtth hopehprghulhhmtghksehkvghrnhgvlhdrohhrghdprhgtphhtthhopehgrghrhiesghgr rhihghhuohdrnhgvthdprhgtphhtthhopehgrhgvghhkhheslhhinhhugihfohhunhgurg htihhonhdrohhrghdprhgtphhtthhopegtmhhllhgrmhgrshesghhoohhglhgvrdgtohhm pdhrtghpthhtoheplhhinhhugidqfhhsuggvvhgvlhesvhhgvghrrdhkvghrnhgvlhdroh hrghdprhgtphhtthhopehruhhsthdqfhhorhdqlhhinhhugiesvhhgvghrrdhkvghrnhgv lhdrohhrgh X-ME-Proxy: Feedback-ID: i8dbe485b:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 4 Mar 2026 11:29:13 -0500 (EST) Date: Wed, 4 Mar 2026 08:29:12 -0800 From: Boqun Feng To: Alice Ryhl Cc: Christian Brauner , Boqun Feng , "Paul E. McKenney" , Gary Guo , Greg Kroah-Hartman , Carlos Llamas , linux-fsdevel@vger.kernel.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 1/2] rust: poll: make PollCondVar upgradable Message-ID: References: <20260213-upgrade-poll-v2-0-984a0fb184fb@google.com> <20260213-upgrade-poll-v2-1-984a0fb184fb@google.com> Precedence: bulk X-Mailing-List: linux-fsdevel@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 Wed, Mar 04, 2026 at 07:59:59AM +0000, Alice Ryhl wrote: [...] > > > + // If a normal waiter registers in parallel with us, then either: > > > + // * We took the lock first. In that case, the waiter sees the above cmpxchg. > > > + // * They took the lock first. In that case, we wake them up below. > > > + drop(lock.lock()); > > > + self.simple.notify_all(); > > > > Hmm.. what if the waiter gets its `&CondVar` before `upgrade()` and use > > that directly? > > > > > > let poll_cv: &UpgradePollCondVar = ...; > > let cv = poll_cv.deref(); > > cmpxchg(); > > drop(lock.lock()); > > self.simple.notify_all(); > > let mut guard = lock.lock(); > > cv.wait(&mut guard); > > > > we still miss the wake-up, right? > > > > It's creative, but I particularly hate we use an empty lock critical > > section to synchronize ;-) > > I guess instead of exposing Deref, I can just implement `wait` directly > on `UpgradePollCondVar`. Then this API misuse is not possible. > If we do that,then we can avoid the `drop(lock.lock())` as well, if we do: impl UpgradePollCondVar { pub fn wait(...) { prepare_to_wait_exclusive(); // <- this will take lock in // simple.wait_queue_head. So // either upgrade() comes // first, or they observe the // wait being queued. let cv_ptr = self.active.load(Relaxed); if !ptr_eq(cv_ptr, &self.simple) { // We have moved from // simple, so need to // need to wake up and // redo the wait. finish_wait(); } else { guard.do_unlock(|| { schedule_timeout(); }); finish_wait(); } } } (CondVar::notify*() will take the wait_queue_head lock as well) > > Do you think the complexity of a dynamic upgrading is worthwhile, or we > > should just use the box-allocated PollCondVar unconditionally? > > > > I think if the current users won't benefit from the dynamic upgrading > > then we can avoid the complexity. We can always add it back later. > > Thoughts? > > I do actually think it's worthwhile to consider: > > I started an Android device running this. It created 3961 instances of > `UpgradePollCondVar` during the hour it ran, but only 5 were upgraded. > That makes sense, thank you for providing the data! But still I think we should be more informative about the performance difference between dynamic upgrading vs. unconditionally box-allocated PollCondVar, because I would assume when a `UpgradePollCondVar` is created, other allocations also happen as well (e.g. when creating a Arc), so the extra cost of the allocation may be unnoticeable. Regards, Boqun > Alice