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 8E38E369225; Thu, 18 Jun 2026 18:20:09 +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=1781806813; cv=none; b=LEcmQVawoCyDBffXZCjKyjHgeCbqN+ZdloGNkEkIHDT/9CRTtayudR+Zo2dWiGQVstPEM2j+RcuOFxy8pGZFVcFUv2Q6q2wmOYzzVBApJ0tHJfcA491MKhQfBu41Oyz6ixemmTTz8N0B7WPB/aLB0ZwB4qFsywSn0KxIPrhB18Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781806813; c=relaxed/simple; bh=xLHdRZoLD2+fYkct+eQOAuBYheYtdoRKbERsKRxzOJE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=NPcOp4LYk51gLMZOZZm1CbtPhd4jzDqDXnP7hHEvPunWus1peKNycjt+/XdYDlaXmcHn8GpaR6Toaf38Z2cIUxRPNh3oX3/71cMegI9qbtqMmb9HZM55NgLIYxOWtwogMRE+vtvj2NpbfFQ7YLsjbrQBtif811b6oQr1x9SthHU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=YfOhqeQz; 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=pass 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="YfOhqeQz" 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=nl4WGWLHU2nDZWMLWrJ7XgtTVp0Yzn1ezTw1CgqCOi8=; b=YfOhqeQzj9WoV+oRg3QwFhQ9jt CpxcX52Y91jRDKTVtVrVV8WoNUJsjKYKuhxKCWQ5IJ3VDaIvT86OqGZqrhfV0zIbNUby5ohaanAM9 veHKDsx3ZOnsyW2V/+aBR9G/Y1SGWz24Tv7KvWmsPt8p4GORTJB0oHktohjR7Z1MnUCusjuWbkuYn MGTRDgJQ+xZWwgzh4rJ1O+vFXf564efpRh/HOq0YZiiH6kHYxIABUusbolD3azapkziAnrVx2/dXY KboJcKuC4N08JqIjCzHahTrThmMXu+TrRqSQsKx8QWMdjy8qQkAIAY2YD8lHQ4v+k7M4vfUmyEW1r F0simKYg==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1waHLS-0000000Etdk-2he3; Thu, 18 Jun 2026 18:20:06 +0000 Date: Thu, 18 Jun 2026 19:20:06 +0100 From: Matthew Wilcox To: Christoph Hellwig Cc: Pranjal Shrivastava , Trond Myklebust , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Anna Schumaker , Shivaji Kant , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH v2 6/7] nfs: Optimize direct I/O to use folios for requests Message-ID: References: <20260616134000.2733403-1-praan@google.com> <20260616134000.2733403-7-praan@google.com> <7ee3bcfdd6126c93cbb1c219bf601182b95c10d9.camel@kernel.org> 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, Jun 18, 2026 at 07:10:45AM -0700, Christoph Hellwig wrote: > On Tue, Jun 16, 2026 at 05:23:48PM +0000, Pranjal Shrivastava wrote: > > AFAIU, the MM subsystem explicitly ensures that every valid struct page > > is part of a folio. > > It is definitively not what the vision for the folio is, although if > I'm not mistaken it actually is still true right now. It's not true, eg, for slab. While there's still a struct page there for slab, there's no refcount and flags like PG_locked have different meanings. You'll get into a lot of trouble trying to treat slabs as folios (and that will include assertions tripping). > This whole > area is a minefield unfortunately, and we also ran into it with > iov_iter_extract_bvecs and the earlier block code it was extracted > from. Adding the relevant people and lists, but for now your best > bet is to stick to what the block code does or even better reuse > as much as possible of that code. Yes. Fundamentally, it is no business of the filesystem what the iov_iter refers to. We can do direct io to slab memory, vmalloc memory, memory that doesn't have a struct page (eg iomem), or whatever we choose.