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 65559231A23 for ; Mon, 27 Oct 2025 13:55:16 +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=1761573316; cv=none; b=VGnRX00sp4WSDUaPQSYtCIwf/OIBBHsZs1Mo4fiABX8lyJsrCcXSab6ChaZ8ByX+dw751BGy07iiLVskeQtuseffJwF0lJp6ekNdDMGTDEh3qqgWgyhppUOYe27Fln1aQCG7tS/JuMxVpga1hq2k+9hqD7oEdceExkPCfll+UeA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761573316; c=relaxed/simple; bh=3oN20YFKF3Dd9pQGT13P4lnNhqwhdNLNtXpCH4DswK8=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=D63gPQkX/x4XFeCEoxo89ZQxAO4ZmPEZ+3P5weOWEoxve/r5yLZQSdgl7ATBp3FG50/vuWBuWcJYZE4oY6jNksOGcct0QKzg+QkmRXCPLMFay771DQbmVjDjqezsJ6EQSR3FoHZ10BA8R77B3O1AWRm5gQaYEv8SWb8lF29gNss= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gRVyQbrH; 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="gRVyQbrH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0B77FC4CEFF; Mon, 27 Oct 2025 13:55:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761573316; bh=3oN20YFKF3Dd9pQGT13P4lnNhqwhdNLNtXpCH4DswK8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=gRVyQbrHvafVUlJqE88xWbzeJsvKTAsEJaCXvn8h5ZWc8EsKxDB0dTpuazHXDr8Jr LBuOU8P8YJms5VVRXG4+a27XdhORcd9GSUpK+QZtMs8utJU+CxxjlDI0iqRO/5ib8m HndUxRgWSxYW6Y/W1ZG+xh6kyWNgKhP2FPdpmZAkk4KI1C1RbZQRmIq5EoGiAcmQd8 Gf1E0r32ZDPIZvF/qF42tjMZHwzjjOg/+K0Cu9k4vVJW6q6o0eUfoifW2kZA3QonTu ElVz8W35UyYsdyLxh9zugI3DOhFx1JfqgjT4iYTQUW1kmgaUmdZD/UuFPqIAG26ojD KqUCl7Gf9kKqA== Date: Mon, 27 Oct 2025 09:55:14 -0400 From: Mike Snitzer To: Christoph Hellwig Cc: Anna Schumaker , Trond Myklebust , linux-nfs@vger.kernel.org Subject: Re: [v6.18-rcX PATCH 2/3] nfs/localio: add refcounting for each iocb IO associated with NFS pgio header Message-ID: References: <20251027130833.96571-3-snitzer@kernel.org> Precedence: bulk X-Mailing-List: linux-nfs@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 Mon, Oct 27, 2025 at 06:19:16AM -0700, Christoph Hellwig wrote: > On Mon, Oct 27, 2025 at 09:08:32AM -0400, Mike Snitzer wrote: > > Improve completion handling of as many as 3 IOs associated with each > > misaligned DIO by using a atomic_t to track completion of each IO. > > > > Update nfs_local_pgio_done() to use precise atomic_t accounting for > > remaining iov_iter (up to 3) associated with each iocb, so that each > > NFS LOCALIO pgio header is only released after all IOs have completed. > > But also allow early return if/when a short read or write occurs. > > Maybe just split the pgio instead? That's what a lot of the pnfs code > does. I already tried that, in terms of frontend fs/nfs/direct.c and then supporting fs/nfs/pagelist.c changes; ended up being pretty nasty (and overdone because in general the NFS client doesn't need to do this extra work if its not using LOCALIO). We only need this misaligned DIO splitting for LOCALIO's benefit because in general the NFS client is perfectly happy handling misaligned DIO (and sending it out over the wire).