From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 5EB0E25B08D for ; Fri, 22 May 2026 09:14:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779441285; cv=none; b=VzNmQjegRQDMsTJayKo+F4BiEoKd71voFijFXe1HwDs2ywOp0Ok9O7G6/7/XFvxII22wzaHa7MyppExvztLz9bm1yOoYlIB/+0zPe4fcGJhUCwrpBOJ5K1uO6xmPmQHwd6OI93HwLwRZb/bTONsls+xRGe4aQIq8+QmhnaTLp3M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779441285; c=relaxed/simple; bh=OLoRVBjatTALAV4XJXo0G+ijD9hWmMpehwcicZTJc1Q=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NF4SbNN1u1uSYNkWnIKehyCMKc76Yzl4Ci7tOA4kUhrhLzORWVCPGkVXu39zxrnota5IvCWJ0gSPBQ3+EfV2MGGlK9YJOfmTNRR41mz/E3E0bpsLfMM5zePPv3e4xsFQ8/6IxDEyif7GOgozvuU5HUldRD3CwZi3POv9KDclOSY= 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=nozd5eG8; arc=none smtp.client-ip=90.155.50.34 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="nozd5eG8" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=6RgihfIhG/pKXUG0PjaYx/dhGJXOxjOy021ob+Z9bng=; b=nozd5eG8IR4fEGxBP9Uy9KQEvy tEarQLLhA+GQFmEA29G9ebW2vSgAywpk7bXS5nP/XuL7BQcEsUDoPvhfnzGBp2c/0QeR0Fh/VrmqD YsB1oKnJD5jLAzM6M7K5YGaUPA0+cl1xk7CUsQfW+K0SWvTMyzW/4f72VCe/d9ibQjr6o8rbukU1u z8h1YLvdQctOfYfv2Ny9r6O5PRrrRmuF89rKyrFfd8VtLIel48398iczdFQv0nxIQQK5ZdLpYdUFm v5WGlbq2tzck7BAaT2xK9WnpvYfsuNbT46dCGi36KOX+ddWzy1YracxwwV1Wyk6vdla/HJ9DeCz8q 5Uol5y6w==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.99.1 #2 (Red Hat Linux)) id 1wQLxl-00000009rbn-34pQ; Fri, 22 May 2026 09:14:37 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 48E72300329; Fri, 22 May 2026 11:14:36 +0200 (CEST) Date: Fri, 22 May 2026 11:14:36 +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: <20260522091436.GT3102924@noisy.programming.kicks-ass.net> References: <20260521095926.29363-1-peng_wang@linux.alibaba.com> <20260522085513.GN3126523@noisy.programming.kicks-ass.net> 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: <20260522085513.GN3126523@noisy.programming.kicks-ass.net> On Fri, May 22, 2026 at 10:55:13AM +0200, Peter Zijlstra wrote: > 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. Also, perhaps reduce MAX_READERS_WAKEUP when in the 'writer' phase of things.