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 9A9DEC46CD2 for ; Mon, 22 Jan 2024 21:10:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D3F46B0085; Mon, 22 Jan 2024 16:10:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 282E56B0087; Mon, 22 Jan 2024 16:10:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 124A26B008A; Mon, 22 Jan 2024 16:10:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id F2E306B0085 for ; Mon, 22 Jan 2024 16:10:48 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 895EDC0A3A for ; Mon, 22 Jan 2024 21:10:48 +0000 (UTC) X-FDA: 81708191376.14.383068A Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) by imf20.hostedemail.com (Postfix) with ESMTP id 924E91C0007 for ; Mon, 22 Jan 2024 21:10:46 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="tq4/ATXl"; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705957846; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=gbck5AucTZaxjbWeuuYe5wNSP+bnbEh0aXTJXBNZvyM=; b=UFoqFovmjQgCUEInI2wRb4Tygj394UqrcyAVPjBxsrBAIC+l7rlcgb6e8QdqdKVFkAJRgg dbBb//5y3zwAAHh+5NT3BZ+hyhUSn7Z1ofsYo7uiDkFJ6BI3ZYjK75A++3U6ybkzT2jUda piYpEluVFMPQj+0qAn7g/IbKApiaXqU= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="tq4/ATXl"; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf20.hostedemail.com: domain of david@fromorbit.com designates 209.85.214.177 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705957846; a=rsa-sha256; cv=none; b=be7XMNOuhfXPOKyiO1MXeG9lb7CkEXrUr6IOXEVTrbbnas4jzVqOcEsh8mAzOyjLIQoYek QaqSrF6TduAFkBQqdUsiry20LkKX6jHqMlj3jd98kdtoYQxAXnSI1T/VYDOAdMxStJiEUD AHSVWkQQDD87uO/jvWL1mdmNRYQom14= Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-1d71e1d7c78so18781935ad.3 for ; Mon, 22 Jan 2024 13:10:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705957845; x=1706562645; darn=kvack.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=gbck5AucTZaxjbWeuuYe5wNSP+bnbEh0aXTJXBNZvyM=; b=tq4/ATXldxBfAyBXgbwV0ddTMmuoGTgKmffFMFxhWp7J08w5kODU2mUsA30Tns9xdd Cyr+uERFw8CdFG/GS1OvaPcLe/yH+RLR6QjkhxpvljOWDQn2yxeIGwWU+mB1IlTvfE8M o9M7qU6Gx8inWBG1S7hpQ8CRaltG3Wtns6J2fjL4SJo96jjdE1PmA/1auPo/UiPe7bPg 4VQOXh0uTf3UCc6j2JrVbr8Ff98AwLHWALB1I9W33EVNtADA5/w2OZREGnMlEHqDArxh lRa/MTFamrqzNp8JtC59Ov7DjZnS/h14oZhIqEeHAgfEGS9H64kyRpZd7/HI0fuW/nmg luww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705957845; x=1706562645; 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=gbck5AucTZaxjbWeuuYe5wNSP+bnbEh0aXTJXBNZvyM=; b=WZHWmNDX/F2Ev41TXnUflCzhdqgkbR7uQHHVjE2r9lPCiNNlcpLiTrp7dDNO0bLocI WcTeYuJkvkRR5eUIh1dUNhGVDEWFVQA6tVX7oIq0VXOJHiZM7e+1tnsRMcVzSZjgsVDs yW3B3FKWZiTJ/jpOZVlRvMt4maXo/awweUHY9MboZRIHsnpByBe11aSsqVWIxFADu4GE i+bECWILYOwDG9DKPaV2DNJzRTi9xrmnKHcbBia5alkZJ0SdDWcwEeBaa4u/xcO1pGhn B8+O1FRsG9VHvn9fv4SNXSWGT7Hpa+fLDpCf/xA/ldjXKwIHTyuuwMQIGE8SYeOrXIdU 4QwA== X-Gm-Message-State: AOJu0YwbkNAwGi5e2M8fza3okHo7LTnVTbXYZBEGF23xKfuWWruFnfG5 IcHYkBeVDecYCb75BZeVUBRBW1PET9iZHM3ff8YNm3xUqKdlKLeSgan1zDrqY20= X-Google-Smtp-Source: AGHT+IHUu3jLG0QUgF7pUGQTAj/j46q0ifGLwypCNt/gsq+Kex4/+H6n2AOh5+p3Xnl4HX8Pfgsp5w== X-Received: by 2002:a17:903:1c4:b0:1d7:2d68:cee8 with SMTP id e4-20020a17090301c400b001d72d68cee8mr2356123plh.45.1705957845195; Mon, 22 Jan 2024 13:10:45 -0800 (PST) Received: from dread.disaster.area (pa49-181-38-249.pa.nsw.optusnet.com.au. [49.181.38.249]) by smtp.gmail.com with ESMTPSA id i10-20020a17090320ca00b001d737d51411sm3636211plb.227.2024.01.22.13.10.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Jan 2024 13:10:44 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rS1Z2-00Dvph-2d; Tue, 23 Jan 2024 08:10:40 +1100 Date: Tue, 23 Jan 2024 08:10:40 +1100 From: Dave Chinner To: Christoph Hellwig Cc: "Darrick J. Wong" , linux-xfs@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 2/3] xfs: use folios in the buffer cache Message-ID: References: <20240118222216.4131379-1-david@fromorbit.com> <20240118222216.4131379-3-david@fromorbit.com> <20240119012624.GQ674499@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Stat-Signature: ohkhdhu4p77ds3xnpewanga4hk8w1kf3 X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 924E91C0007 X-HE-Tag: 1705957846-792991 X-HE-Meta: U2FsdGVkX186iRibEJxmkhSX/Qb4mOvqFQc1eE7tWIyQiIFKL428iRG1B4TlqbSznNLjO/Bdw5MN0yVmOI4Mjq5BXzwawXaYW6muwOfAtDMSuDnRiq8l7rrZYs9z36gpb5SjtoNiecfOcZwHu4pPtDjMMuAHUOZ0GFhRcd02KBHkQuqJCpAWlNlpeSeL07ibw7MmlMYeuxuJagaUa0I8XZ+1yaizAe22F36fa0MI+NbKLL7a4M2EoMBUhtQ2ICESloYVdX0zc2zN+E9c10XqBW7nIkPhnUNvORP5UBpX+pGKJjMmqPSN0MRrRLqELpZ2vhq6DqkCLIET91WC1D8zo0jZkt6Br/jkQetV5T/44PAbNFWT0QEYOw1vGleDdxemIjwxdbcM4/vmavACDG7sZs8IJZrVgcV0Drf4zNuZxFQjxSXDT+Vq+4N8ku8Xi1fUA8oOfiyhDiuIJsCNxTGf+Cr70o+nqkg7uZ8tbGMczEdX4RFBjP8RSW1YsczdSO1gbqQz/Q+JhEXvtK1lUOh4VsSFnXi8hgG3jKxnvf4Je2YYzkrdSE/U+IwIFvot9F4PKtR0urCsD8/v/DJ/9wAaFMxQlBv2hoD3rjPW18jTY7dcJszKGB0Eh7WXWeEvtqsMOUnlD2Pp2Ep3BD8ex187d6IVL/mn72G7syY5Z2d9B8FXIqjyoD3Zo+wV9LF/L9gTUZl2rp0pER57ehpshTiGB2EU2a62SvcO7qViw+4RAPinRSaLvT0gY0Pi07DwiqZAYxdESE/bv4BlUxSZdfLpfoMK+10ngQ6+Uldqt6isGcbdM3Ge9QvsYZLz5kEwHKCBgjPpPGor61Ea3gt4prGPB9k6TlaRch4MnrHKF6oL/67IM8iwUwOvLT3lXflSNmhtZtehClsCNgseADVWC/nUQHESw9vDJAQmuG4VGcWMQhZhMKRdUe0ylh1/KoQqFMTuQrREjGHl/sIIIuKVaWC wFK9GIom D+l0M2hG9QOZCNGdbQ+gzpFZ8ffNxCIfhsF3sb41npY1t8qsqIucRPFCtEgmuoezgn1PcAaVxNYaorD/9tKAaK/+kGr08ggtnUwwUkmvQkkVKuXCD+kOWJnwPWTECcmSB2/MSzf95QJL8a1V215eUSa0ob9Tp1IPVrK5tNgODiWoHHmrMUgEK7Hn/9lwonfvBBIdpSV96Ktjiz3vcTbB07ofd8CHxPeZKSPIqXjFmXkMqNqeSFBlTT+5vkuLW/SuVQbhk8wNyyg2n7KI0rkAHolErMN4J9C1E0spFITjZTztqRXmhb5gqLEydq0IQ2uOF6Nknz27LY4HpRipIgIB9H3c/uU9Gap7UDTC/MSzzUe+3yVxZJgv/I8u9hRPRYXYaUfoSjTwuWkZ69CzZpkV8J1Fcf90RkWb+GKD2KvzKPkeRvsg03q3BBDpAXlypvtmsbbJT X-Bogosity: Ham, tests=bogofilter, spamicity=0.000112, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Mon, Jan 22, 2024 at 05:18:58AM -0800, Christoph Hellwig wrote: > On Mon, Jan 22, 2024 at 11:05:20PM +1100, Dave Chinner wrote: > > I haven't looked at what using vmalloc means for packing the buffer > > into a bio - we currently use bio_add_page(), so does that mean we > > have to use some variant of virt_to_page() to break the vmalloc > > region up into it's backing pages to feed them to the bio? Or is > > there some helper that I'm unaware of that does it all for us > > magically? > > We have a kmem_to_page helper for chuking any kind of kernel virtual > address space into pages. xfs_rw_bdev in fs/xfs/xfs_bio_io.c uses > that for a bio, we should probably hav an async version of that > and maybe move it to the block layer instead of duplicating the > logic in various places. Yeah, OK, as I expected. I'd forgotten that we already play that game with xfs_rw_bdev(). I think we can trivially factor out an async version and call that from the xfs_buf.c code fo vmalloc()d ranges, so I think I'll work towards that and actually remove the bio packing loop from xfs_buf.c altogether. > > Yeah, that's kind of where I'm going with this. Large folios already > > turn off unmapped buffers, and I'd really like to get rid of that > > page straddling mess that unmapped buffers require in the buffer > > item dirty region tracking. That means we have to get rid of > > unmapped buffers.... > > I actually have an old series to kill unmapped buffers and use > vmalloc, but decided I'd need use folios for the fast path instead > of paying the vmalloc overhead. I can dust it off and you can decide > if you want to pick up parts of it. I wouldn't worry about it too much - the rest of it is pretty straight forward once we know inode cluster buffers are working correctly with single large folios and we always fall back to vmalloc(). Cheers, Dave. -- Dave Chinner david@fromorbit.com