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 X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2AB76C33CA9 for ; Mon, 13 Jan 2020 17:54:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E392C214AF for ; Mon, 13 Jan 2020 17:54:40 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JoDbgk3K" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E392C214AF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 85B1B8E0005; Mon, 13 Jan 2020 12:54:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80B298E0003; Mon, 13 Jan 2020 12:54:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 721508E0005; Mon, 13 Jan 2020 12:54:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 5F6DA8E0003 for ; Mon, 13 Jan 2020 12:54:40 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id F0CD23AA7 for ; Mon, 13 Jan 2020 17:54:39 +0000 (UTC) X-FDA: 76373361078.17.jar21_b97fa833eb2a X-HE-Tag: jar21_b97fa833eb2a X-Filterd-Recvd-Size: 2958 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf01.hostedemail.com (Postfix) with ESMTP for ; Mon, 13 Jan 2020 17:54:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.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:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=v68KOmmFCgojskPM3niSU92RDz2UGXctd3aEcUGr1z0=; b=JoDbgk3KvfTL3TCtvdKWEkP2I GGxzbOkOAhh4bu+x8KEXH765FH6bbPxzLnlxNd6Vo1qGp7Oy+ocl7praB1F0ZFFcPrF1w4l3JDfmS 8NNXB5UE4oCt32dAVbZ+aRCpZK+jRuCX+K1o7Fy8T2Y/G4a2OoPFm+NoHeyjkZjj+QNZP6pSCUgHA f87JzB4e8x3h1MUsbJlOKaBJykMaZG2/khdlcFQWa1y209JIWtvajJF/+U3lPa++T0SsC6yec7F+p ElANtlsCvb30WH6eXo3R/reXUHHDy2TjhScLZ5srtYZIy+l34p4/NOd+9IOt6kJhbPr11njpxo1+r ABzvCY8BA==; Received: from willy by bombadil.infradead.org with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1ir3vA-0006y8-8w; Mon, 13 Jan 2020 17:54:36 +0000 Date: Mon, 13 Jan 2020 09:54:36 -0800 From: Matthew Wilcox To: Chris Mason Cc: "linux-xfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "jlayton@kernel.org" , "hch@infradead.org" Subject: Re: [RFC 0/8] Replacing the readpages a_op Message-ID: <20200113175436.GC332@bombadil.infradead.org> References: <20200113153746.26654-1-willy@infradead.org> <6CA4CD96-0812-4261-8FF9-CD28AA2EC38A@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CA4CD96-0812-4261-8FF9-CD28AA2EC38A@fb.com> 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 Mon, Jan 13, 2020 at 04:42:10PM +0000, Chris Mason wrote: > Btrfs basically does this now, honestly iomap isn't that far away. > Given how sensible iomap is for this, I'd rather see us pile into that > abstraction than try to pass pagevecs for large ranges. Otherwise, if I completely misread this at first and thought you were proposing we pass a bio_vec to ->readahead. Initially, this is a layering violation, completely unnecessary to have all these extra offset/size fields being allocated and passed around. But ... the bio_vec and the skb_frag_t are now the same data structure, so both block and network use it. It may make sense to have this as the common data structure for 'unit of IO'. The bio supports having the bi_vec allocated externally to the data structure while the skbuff would need to copy the array. Maybe we need a more neutral name than bio_vec so as to not upset people. page_frag, perhaps [1]. [1] Yes, I know about the one in include/linux/mm_types_task.h