From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13B4FC433EF for ; Thu, 19 May 2022 08:25:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 993DE6B0072; Thu, 19 May 2022 04:25:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 91CED6B0073; Thu, 19 May 2022 04:25:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E5106B0074; Thu, 19 May 2022 04:25:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 6F25E6B0072 for ; Thu, 19 May 2022 04:25:31 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4471B9EB for ; Thu, 19 May 2022 08:25:31 +0000 (UTC) X-FDA: 79481808462.15.C01B584 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf20.hostedemail.com (Postfix) with ESMTP id 4AC231C00DB for ; Thu, 19 May 2022 08:25:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; 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=NMVgWH8Av+/hGKuajJ4b2VmD67IiLz5BfVbltl8x7Rk=; b=wNSo9a3yLDZhwGX5vSnu8bsz/H +XKZomAL3wu02/BFL23DGpYhU0CuJ22mPdBv5XPWKw+Ps4D/qSaTKADz7BhXraSpK1JC7717YTlg5 MjIB5axQHbw8VcU5mKCxCE25Voq42yl7Y1lGjxDOggE4lAlRmtd+3VZJmhrWDgYMU+I46oKqZkjYE TOAj6PClBgrVMjjLRFkTK5X3LcZBISJERGzoBPVD3erHPo46MJT9DDkVI2rmaSqmvAkXl2NzBI0+v hnHlKxWbVjog/pQcW8kbHO9f+47KrlL+UlPmiZZuvarsirayZ/20Hh4Bd3heyfa3aDHLQpr9DCFko USJrzhvQ==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nrbTM-005omx-39; Thu, 19 May 2022 08:25:28 +0000 Date: Thu, 19 May 2022 01:25:28 -0700 From: Christoph Hellwig To: Stefan Roesch Cc: io-uring@vger.kernel.org, kernel-team@fb.com, linux-mm@kvack.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, david@fromorbit.com, jack@suse.cz Subject: Re: [RFC PATCH v3 04/18] iomap: Add async buffered write support Message-ID: References: <20220518233709.1937634-1-shr@fb.com> <20220518233709.1937634-5-shr@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220518233709.1937634-5-shr@fb.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4AC231C00DB X-Stat-Signature: 58trghi6p3yx4i8qfyzeazbezfixuw4j X-Rspam-User: Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=wNSo9a3y; spf=none (imf20.hostedemail.com: domain of BATV+015a865715d1323b7cbd+6843+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+015a865715d1323b7cbd+6843+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none X-HE-Tag: 1652948718-32055 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, May 18, 2022 at 04:36:55PM -0700, Stefan Roesch wrote: > This adds async buffered write support to iomap. The support is focused > on the changes necessary to support XFS with iomap. > > Support for other filesystems might require additional changes. What would those other changes be? Inline data support should not matter here, so I guess it is buffer_head support? Please spell out the actual limitations instead of the use case. Preferably including asserts in the code to catch the case of a file system trying to use the now supported cases. > > Signed-off-by: Stefan Roesch > --- > fs/iomap/buffered-io.c | 18 ++++++++++++++++++ > 1 file changed, 18 insertions(+) > > diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c > index 6b06fd358958..b029e2b10e07 100644 > --- a/fs/iomap/buffered-io.c > +++ b/fs/iomap/buffered-io.c > @@ -580,12 +580,18 @@ static int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, > size_t from = offset_in_folio(folio, pos), to = from + len; > size_t poff, plen; > gfp_t gfp = GFP_NOFS | __GFP_NOFAIL; > + bool no_wait = (iter->flags & IOMAP_NOWAIT); > + > + if (no_wait) Does thi flag really buy us anything? My preference woud be to see the IOMAP_NOWAIT directy as that is easier for me to read than trying to figure out what no_wait actually means. > + gfp = GFP_NOWAIT; > > if (folio_test_uptodate(folio)) > return 0; > folio_clear_error(folio); > > iop = iomap_page_create_gfp(iter->inode, folio, nr_blocks, gfp); And maybe the btter iomap_page_create inteface would be one that passes the flags so that we can centralize the gfp_t selection. > @@ -602,6 +608,8 @@ static int __iomap_write_begin(const struct iomap_iter *iter, loff_t pos, > if (WARN_ON_ONCE(iter->flags & IOMAP_UNSHARE)) > return -EIO; > folio_zero_segments(folio, poff, from, to, poff + plen); > + } else if (no_wait) { > + return -EAGAIN; > } else { > int status = iomap_read_folio_sync(block_start, folio, > poff, plen, srcmap); That's a somewhat unnatural code flow. I'd much prefer: } else { int status; if (iter->flags & IOMAP_NOWAIT) return -EAGAIN; iomap_read_folio_sync(block_start, folio, poff, plen, srcmap); Or maybe even pass the iter to iomap_read_folio_sync and just do the IOMAP_NOWAIT check there.