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 3D81CC4725D for ; Fri, 19 Jan 2024 07:03:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 769B06B0074; Fri, 19 Jan 2024 02:03:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 71A186B0078; Fri, 19 Jan 2024 02:03:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E1636B007B; Fri, 19 Jan 2024 02:03:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4C42D6B0074 for ; Fri, 19 Jan 2024 02:03:58 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id E21CA140630 for ; Fri, 19 Jan 2024 07:03:57 +0000 (UTC) X-FDA: 81695170914.01.89A92AB Received: from mail-ot1-f48.google.com (mail-ot1-f48.google.com [209.85.210.48]) by imf03.hostedemail.com (Postfix) with ESMTP id 0127D20017 for ; Fri, 19 Jan 2024 07:03:55 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=t4bJ50I8; spf=pass (imf03.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.48 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1705647836; 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=X8Arh70fDu03R+d/hJeo95Gy62+3eiFjD0bJ2gIwqPM=; b=1B6TMikvQTO7D0jy8WG6CPbXqdlgA4btl276otHiqbTx8Lorp8C7iBoCb8ULk+tjKGcAon xLtkpSV88lKJz0qzB/UCkZAtD5/hg2nTbt2VA9YUMwSkDa51Ovir623/UuBoDv6bfOxaAJ s/mgs8W6mU9BBYSggnQPpD2Met39V38= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705647836; a=rsa-sha256; cv=none; b=NoYLVCfdLG/ytKys5V+qTwf2+7cg0eJk6ALBUe06ilOjWNjB0kwFvBE9SXozpZnTmCeQPd WiPHrZw8woJq6frAngQsRQRm4Mm67qrtQwHyVHr8JSDw6rttDF4l6CiCsiAkW76EmHv/sp NPLsfQmgfQ5SyCq0oCVh47PfJhEfKLA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b=t4bJ50I8; spf=pass (imf03.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.48 as permitted sender) smtp.mailfrom=david@fromorbit.com; dmarc=pass (policy=quarantine) header.from=fromorbit.com Received: by mail-ot1-f48.google.com with SMTP id 46e09a7af769-6dddc655a60so308523a34.2 for ; Thu, 18 Jan 2024 23:03:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705647835; x=1706252635; 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=X8Arh70fDu03R+d/hJeo95Gy62+3eiFjD0bJ2gIwqPM=; b=t4bJ50I8YcpJysFlhIk6FXNGxg4Z2VjzW75ieb90oPqvCVWqZrEqWaa8VC6yXYpokv 99hHWrni6GJDGmbQZoYh8Dvv7uH4iGl0+HAwPunK+10uxAouEnVmnFk0ovlmmpYxe79L 5vVVBYLaQUMbWQaOYzZFg72uIDSwLhguQvlb6o7nwEdzrGVMT+SqFWOKKA79w3eSLqXy xmTRTb2V9e11ORuyaJgQzXJItjesdwEnuvmq+5Fl55N6xelBe08YHJUgrLJUmo2yzH1j xZ00NbO/fXCFk88b269skcNElkZUOt07d1ptQJIvqWHjlBKiQSUwL9D3iBTNN0d/VWfY SfJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705647835; x=1706252635; 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=X8Arh70fDu03R+d/hJeo95Gy62+3eiFjD0bJ2gIwqPM=; b=kCTl146Q+ZLniRZbdZZnjVTj/Y1M/DLDz3OnTpQaOIyNwj2cgHHX5g7ANL3T3SYwvi L54gV/TBHncjOUu5bTPm10FlXiDxxxuouZceszgQ4MnUDtL2glg5hduoy1BTzYMboQ6B 8uY+gAdn4S1BycOeytpaV/VwZhaCoUYWQPcbbsjKy9Zb5vt1U2JVjCIzip0YDHY6nDOx TO8HFyfZFi1q54qm8+SD/eNRh5Qsz0tM6LGTouP9bX8qGurBFLCL6Gb+3fWOoNja9vok butZ/gnrVQsis3RUmNHfgkW63HrBnVb5El6xk7PbHKkRlUys3+dPxK62CQPeOOuE3DI8 cyZA== X-Gm-Message-State: AOJu0YwzgRRYVw+kKztEi7s6XGLXgYqsl8yq4LeDnbl5N3a8/AtKL+Ef f0O7j1N/jJ1tmYG2+07iF0tUuVZixGejCcHs4mafrXmkq/1kfI3fAqRIyocczCw= X-Google-Smtp-Source: AGHT+IGuHSygKsIPmCDnm1lLQ8LYQFBOogvEUeCXCoi5rvnUk3bTNh1cG6MUoT1bMmn9V+T6HwBtfA== X-Received: by 2002:a05:6359:45a9:b0:176:25b:64f5 with SMTP id no41-20020a05635945a900b00176025b64f5mr2689090rwb.26.1705647834866; Thu, 18 Jan 2024 23:03:54 -0800 (PST) Received: from dread.disaster.area (pa49-180-249-6.pa.nsw.optusnet.com.au. [49.180.249.6]) by smtp.gmail.com with ESMTPSA id q16-20020a056a00085000b006d9aa04574csm4338227pfk.52.2024.01.18.23.03.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 23:03:54 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rQius-00CMBs-2K; Fri, 19 Jan 2024 18:03:50 +1100 Date: Fri, 19 Jan 2024 18:03:50 +1100 From: Dave Chinner To: "Darrick J. Wong" Cc: 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: <20240119012624.GQ674499@frogsfrogsfrogs> X-Rspamd-Queue-Id: 0127D20017 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 86qpjyq43h8mfuuwwyjpa6xix4mikkmm X-HE-Tag: 1705647835-133381 X-HE-Meta: U2FsdGVkX19xz8dru52WT5XEcqaQzcM6BVXtQaglxzvFVtNdA12bt/O0NoNQr8pKdnKaWzwpFwRKjtz0sWqUftIcIxwftQj2PR+IsJnfEcdZfDvKneTjW/x65vOAaqD68pffKpIA2J/lEwhKisNQSxMg0i9UrRAjdk9jUcRPacqmndMpAow4guDBTFozDFCEhAz/2dp1Y5j9Uk0QI2SmbkL1hSffT0Q9HW9A2Mwe6yABxrhSa0jXXOYXh0IvAt6qOV8OrONTQZf45Ug4AI8s3zlf/TI9PFgKhPLGiXE466bJUyENqdYqOTr6eBR5QvXeHuDNBXkN4GNcFvPp/KICckTRdviBj+mBRaN4NcnMlJRnd9SrbazsZPgwAEwJ050WRUfAlNTHPPv5RTUj9TM0oHHG3kYHHxfM6ckYvv9gYQrQKCvjWI26kGhdwbX0YmFEDi5f4S+ulAKc6grQZItI4Ch3aU9G06RZfsquKT1MKj1oSay+bu8f0FJtGVLkSyR7etnazfn+QrCyMbtvdZwKET/bWUBXGwipawByWjuGxJPZf+ITBMX14+ebU/ckAj3YfoS2Tee64LNfpV7D3j1x07zumSoop6qZtTezi+9ZLw3gQr9Y1fBGl0JItOESe1ZyKhe1dgRehCfOYoTkp+QcsC1WczXSqEtSrifNN5pHxCPCgVvuwORnzRqZnQIBEds10C/RjVg20gCXEaFTlm/7+u5jywJPTOvpMwOfq1FIhPUPnz7rf+HAxoedlgZFbiHPLHab5hwu7DK//amyZsOrOVrszW789IFSC7SPH63GyuJEzw0aK4uFhsTqhTNXUQAC3BpOlOiUA2lZF5BQ0N8DrhfbBmO4ybiz/vk/FztrjPXONG1nc3WwGw10K7mkDnOpkHq8AnSpdFe1R95qMrf0KVRDNtq+o32udgpe8BcL9JBK27RomiAMpDOp3UxuyMeJiCrtHx5yMdbtZwHQeRx /4xgJ1qc T1MWLzG90sRy2C10symX2lZ4QdAfhom8ylFHcG6Xq8GyqVjvNeSJRmhjkAkYOyMqnEKKm4A9ZM7poOL52fVHQDZyUIZ9sPQ21bp4RyMZ6FINPbstx080bXevLlvlc2aECo5oLR0VCFLBONs0raq9EDnT6nyTVESU4wbH9djhkiNnW8DwQftB+EQ8gXIbCu/TnvJ8OPG9MqXKVkeeUroc2j1FF9zYrZ/El5JEvbCp+HqCoqKxDuLDcNkY5D7+IVD+XTIQsw6g92SuZ4AfQ/CdS4jVa2D5VNR7bQpd2lJAWQXCG3ccRAAA2G1objRfaTplBmUhuc79m9Mk1BuITVN58btTjF4BWjhMKQgk92nOAKHByuQ9IMvU4rIBtxwKaCuD7JTSdEMAf+/LIZGaSIj16Wwy5418wEy/hklxrpoTtv+yFf5kTOkHBVTs1BYyBkVq10TwEKjRLUl9pwYfyqS9/fV+wtA== 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: List-Subscribe: List-Unsubscribe: On Thu, Jan 18, 2024 at 05:26:24PM -0800, Darrick J. Wong wrote: > On Fri, Jan 19, 2024 at 09:19:40AM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > Convert the use of struct pages to struct folio everywhere. This > > is just direct API conversion, no actual logic of code changes > > should result. > > > > Note: this conversion currently assumes only single page folios are > > allocated, and because some of the MM interfaces we use take > > pointers to arrays of struct pages, the address of single page > > folios and struct pages are the same. e.g alloc_pages_bulk_array(), > > vm_map_ram(), etc. > > > > > > Signed-off-by: Dave Chinner ..... > > @@ -387,9 +387,9 @@ xfs_buf_alloc_pages( > > for (;;) { > > long last = filled; > > > > - filled = alloc_pages_bulk_array(gfp_mask, bp->b_page_count, > > - bp->b_pages); > > - if (filled == bp->b_page_count) { > > + filled = alloc_pages_bulk_array(gfp_mask, bp->b_folio_count, > > + (struct page **)bp->b_folios); > > Ugh, pointer casting. I suppose here is where we might want an > alloc_folio_bulk_array that might give us successively smaller > large-folios until b_page_count is satisfied? (Maybe that's in the next > patch?) No, I explicitly chose not to do that because then converting buffer offset to memory address becomes excitingly complex. With fixed size folios, it's just simple math. With variable, unknown sized objects, we either have to store the size of each object with the pointer, or walk each object grabbing the size to determine what folio in the buffer corresponds to a specific offset. And it's now the slow path, so I don't really care to optimise it that much. > I guess you'd also need a large-folio capable vm_map_ram. Both of > these things sound reasonable, particularly if somebody wants to write > us a new buffer cache for ext2rs and support large block sizes. Maybe so, but we do not require them and I don't really have the time or desire to try to implement something like that. And, really what benefit do small multipage folios bring us if we still have to vmap them? > Assuming that one of the goals here is (say) to be able to mount a 16k > blocksize filesystem and try to get 16k folios for the buffer cache? The goal is that we optimistically use large folios where-ever we have metadata buffers that are larger than a single page, regardless of the filesystem block size. Right now on a 4kB block size filesystem that means inode cluster buffers (16kB for 512 byte inodes), user xattr buffers larger than a single page, and directory blocks if the filesytsem is configure with "-n size=X" and X is 8kB or larger. On filesystems with block sizes larger than 4kB, it will try to use large folios for everything but the sector sized AG headers. -Dave. -- Dave Chinner david@fromorbit.com