From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f170.google.com (mail-pl1-f170.google.com [209.85.214.170]) (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 0A3641C6889 for ; Wed, 22 Jan 2025 23:35:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.170 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737588959; cv=none; b=Ivu6hjolts3DWe9qr5geZQuTLGRiyU5TRkJWYL1mvOB80qYW5XpURilSMXt521PUwrFaCgF1wTvVf+s1yvvoHagkQfSNkfasTgjBbuvt4gAFiGoboeGZ0HF567rML+aPaGT72aQbDtB63K0koYhghk1wOnaSEWdkXZBqYYlHPws= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737588959; c=relaxed/simple; bh=IUIZ7amWJcDTh/AOG8Asjr28ffYWJP9MY3y3xx/ttk0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jM05K2LDcZC3toTNkStFk2NT1eh0qXAkxnvN3oOJJBEoD2p8Knf69AL3001msINLA4GvXcl0Gsc2NNszL2dcCwwCR1PXiWbUCVutVU9me0XWxkWT7+GGpfnX5heypsmmLo+IMIpGgm+ESRL0o0iYQjEV7g6H9R5UOBO1CluC+Gs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com; spf=pass smtp.mailfrom=fromorbit.com; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b=RWC0V26/; arc=none smtp.client-ip=209.85.214.170 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=fromorbit.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=fromorbit-com.20230601.gappssmtp.com header.i=@fromorbit-com.20230601.gappssmtp.com header.b="RWC0V26/" Received: by mail-pl1-f170.google.com with SMTP id d9443c01a7336-216281bc30fso5676625ad.0 for ; Wed, 22 Jan 2025 15:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1737588957; x=1738193757; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=PQIZKSNd8OQ+CuQJmCwdgXHO6+w/Fkh8ODeAu97iHYY=; b=RWC0V26/viuMgjUV9RjNHAlGBbW3+e9hZ5mxpW6JewuU0QessC014Z5DZmVqWfv05I M3xWYt3sGprnPb9Rp4igillDaqU+rsHtEEqmw3Cy1RbNIfv28ZpdVh81GIVn9n8Exdme rrSe7JXQkiJfFaiybvS3VLSlmUWio7oEgO5FV93xgc7oQUfUplG0+N05MGkBQ1MNZqfd 18YjdEjvdm1RKnb0NPry+JlhdGrMpEjSDIsbrKP1doCSiqfGxXyqxWQgQX18twykJHxk HFGVBq8oLUx+WDcwq2M0eVwo90f9cmijlZFzKRBEw0B/BzsmTjYcsYG3vcqo1sqrHXLB W0bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737588957; x=1738193757; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=PQIZKSNd8OQ+CuQJmCwdgXHO6+w/Fkh8ODeAu97iHYY=; b=g32Lwz6ERfGEr3x4d12QtyPd5g2WvNGod56C9K4B32GYKFrRsxbcHa+ER1QTxu1S5G sgo7nq5SPE5f9y0Ygnb2HUISC4yq42lrCzbRdb6wonr2pHpwjWmVU+yWtKJku1AVhWOA P4Kc4O1REHp3A6ZKhFbK2wXH7uCVpn/tZtdC2wAvX/UgPgBnCV2sLPkJhX7CNDGvJD0P qWtzZB2NtdReUCb7FfDCshEkjmzM3wr92ROqbu5ZMfIITng4IZZN1Bwu2RewIc+RhsqY 8SBkHaGWFj2t7654J5CzHqb5aa1EsxK5vIWbJbUV3DSVJbMOacDF92WJS6ppK6lZkCZO KKCg== X-Forwarded-Encrypted: i=1; AJvYcCXxP8UBIi5ZtFRxGW6j1jtryUKRQlZ/9x6sDBMx4H/FQEPFVb6bZX51IitrHVh+L9Y6FeWjuVhGEqNjcz0=@vger.kernel.org X-Gm-Message-State: AOJu0YyRL1rrWMOUwjQiuBLjn0E4nH2pxtwd7sIc33rArisSvnUQXV0G 8JCDVlZzq6K8r3R6+Zi2LZ7IQT0kuBrlSJ/Zau6zLxNgp8JmPWV4J9CbyXEWhd7t4X3hw/hPzk+ X X-Gm-Gg: ASbGnctmdKR8gyvl51xKDQVDvxIzY8k26cszIyXla3nOyRD60qOdY9zdjEfpGGtAs8M mnG/vP7guHpxIeTU6EW149wtmxStQaaKhXZQr0NiAUQMs9K46i9fzBTjXV9v6cyvPFwYnfJUPkh eBd/C9ONVIOBVkJF1zU9EUtJGJB5JVlqsIF8FPlqAuhyWhKuxN83bAzUxy5RXICEQOmimi3e1Cv P/tpUtbxYzfAcV1J8LanIzpuE4+NjhbYm+astgxDuayd2LbJ+WtMFlheli855GBEKXrPjRLD2zv /x763vURkBOESVhCdfPDCDRRG5DjTA5U+Fs= X-Google-Smtp-Source: AGHT+IEbIemosPcPMqz4QUqnOq5Y3a04UAxJv4Gi5UG/0jI/jDEkwZvs5Q/7Vdqfmtw4fKwGDPsy3w== X-Received: by 2002:a05:6a20:4312:b0:1e0:cf39:846a with SMTP id adf61e73a8af0-1eb2159019emr38319317637.29.1737588957316; Wed, 22 Jan 2025 15:35:57 -0800 (PST) Received: from dread.disaster.area (pa49-186-89-135.pa.vic.optusnet.com.au. [49.186.89.135]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72dab9c8dc4sm11899720b3a.94.2025.01.22.15.35.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 22 Jan 2025 15:35:56 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.98) (envelope-from ) id 1takGI-00000009HCE-0jDL; Thu, 23 Jan 2025 10:35:54 +1100 Date: Thu, 23 Jan 2025 10:35:54 +1100 From: Dave Chinner To: Christoph Hellwig Cc: Amir Goldstein , Brian Foster , "Darrick J. Wong" , Chi Zhiling , cem@kernel.org, linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org, Chi Zhiling , John Garry Subject: Re: [PATCH] xfs: Remove i_rwsem lock in buffered read Message-ID: References: <20250113024401.GU1306365@frogsfrogsfrogs> 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 Tue, Jan 21, 2025 at 10:08:10PM -0800, Christoph Hellwig wrote: > On Sat, Jan 18, 2025 at 09:19:15AM +1100, Dave Chinner wrote: > > And, quite frankly, the fact the bcachefs solution also covers AIO > > DIO in flight (which i_rwsem based locking does not!) means it is a > > more robust solution than trying to rely on racy i_dio_count hacks > > and folio residency in the page cache... > > The original i_rwsem (still i_iolock then) scheme did that, but the > core locking maintainers asked us to remove the non-owner unlocks, > so I did that. It turns out later we got officially sanctioned > non-owner unlocks, so we could have easily add this back. I did that > 5 years ago, but reception was lukewarm: > > http://git.infradead.org/?p=users/hch/xfs.git;a=shortlog;h=refs/heads/i_rwsem-non_owner I have no issues with the concept - I have always thought that holding the IOLOCK to completion was how the IO locking should work (like we do with the xfs_buf semaphore). The i_dio_count submission barrier solution was a necessary hack because rwsems did not work the way we needed to use them. What I didn't like about the proposal above was the implementation (i.e. the encoding of rwsem semantics in the iomap dio API and implementation), but there was never any followup that addressed the issues that were raised..... -Dave. -- Dave Chinner david@fromorbit.com