From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (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 C1FC63AC0D8 for ; Fri, 22 May 2026 08:55:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779440124; cv=none; b=QMBhXxbz8G1mn85DWuqwHUNxb9SAfRTGD4903HRkmyaTkrKUNdLEsI1gJwCFwPy2Rt1eNYCxrLuZ0/wRwAShXdoeqrRfKnvWk3gKTAxPj6alNohnZ+E31zxLMtxulxBMEGVybj2AKAsMPPLXUYi/QRaVAkLMmYPKn1YwA8NAQhY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779440124; c=relaxed/simple; bh=8LlU1WNJ+iKITGU9dZQNkNmv2zElpRgPm3JcWI5IiWA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QNa1tBI1jwI/WHj8M/3mWc6XAAIiuVrYT+eVL7jhbs7EC/a9J0CcURp5C51W8xJtaVdVhrkLoYMGWPgq6xcOS9qGAd4NJWA24bs1t5ahyBEUHEL0+dEeHe591hCkGo8sr7coNT1Aac9ylsbYHtFGTIW9Zp6E6f4etoRdmYVKi4M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=e/8tpbcs; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="e/8tpbcs" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=snR3h4X8YVMvtW9rswwRc8m/w1TfhAV/WEatKa7jY8c=; b=e/8tpbcsv0ewbRwThZd4CwGIsD 53FBqbV4Z4WtAdVfSOihBxQLs8c6bcAnNbxmSOFIlkTMzbn9R5C3Su1nl0DOwpkyb15dtYr9uhAUs A0oiOuIr0FbZAmx6vg7vRVHxQ2SB3DaIaGJAPlhjjXGobOEcxXqKZkJukRBlGk6UKDbjEnPpq2NdN r9Ft6MglkXtU608DmHsNBePe1tA8MOPaqNq4gZOMZs+it1uA9tLRk991GS/raEIyMBG+9joGeCIBx VcB2nTfbUlLNPOtj2Zj9LMm4AslqsYoulHJ9iTM2u2ihPsFhZaK8PLIw3wjo/QbU9kwmh670KslF/ nVzAgn+w==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wQLf0-00000003nP2-2MV7; Fri, 22 May 2026 08:55:14 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id AF13E300329; Fri, 22 May 2026 10:55:13 +0200 (CEST) Date: Fri, 22 May 2026 10:55:13 +0200 From: Peter Zijlstra To: Waiman Long Cc: Peng Wang , mingo@redhat.com, will@kernel.org, boqun@kernel.org, dbueso@suse.de, linux-kernel@vger.kernel.org Subject: Re: [PATCH] locking/rwsem: Remove reader optimistic lock stealing Message-ID: <20260522085513.GN3126523@noisy.programming.kicks-ass.net> References: <20260521095926.29363-1-peng_wang@linux.alibaba.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 Thu, May 21, 2026 at 10:08:58PM -0400, Waiman Long wrote: > On 5/21/26 5:59 AM, Peng Wang wrote: > > Reader optimistic lock stealing, introduced by commit 1a728dff855a > > ("locking/rwsem: Enable reader optimistic lock stealing") and made more > > aggressive by commit 617f3ef95177 ("locking/rwsem: Remove reader > > optimistic spinning"), allows a reader entering the slowpath to bypass > > the wait queue and acquire the lock directly when WRITER_LOCKED and > > HANDOFF bits are not set. > > > > This causes severe writer starvation in workloads where readers hold > > the lock for extended periods, such as Direct I/O operations which > > hold inode->i_rwsem for the entire duration of iomap_dio_rw(). A > > common example is log-structured storage where one thread appends via > > DIO writes while another thread tails the log via DIO reads -- a > > pattern seen in database redo-log replay and shared-storage > > replication. > > It is generally assume that reader lock critical section is shorter than > that of writer. In this particular case, does the reader critical section > run longer than the writer's one? Well, that and writers are assumed to be rare. Reader-writer setups where writers are common or even dominant make little sense. And that seems to be exactly this. Then again, it isn't unreasonable to expect it to not perform significantly worse than an exclusive lock. > Reader lock stealing should only happen if the previous lock owner is a > writer. So readers and writer should at most alternately own the lock if > there are many readers waiting. Of course, if a reader own the lock, it will > wake up the remaining readers in the wait queue. Anyway, IIRC I've mentioned phase change locks many times before. And what we have here is an asymmetric phase change. The timeout causes a change to writers, but any one writer completing then switches back to reader dominance. Perhaps look at evening out the phase change. Retain the 'no-steal' phase for an equal duration. Also, 4ms is an eternity, that might need tweaking too.