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 82929C47DD3 for ; Fri, 19 Jan 2024 07:12:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1F59A6B007D; Fri, 19 Jan 2024 02:12:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 17F286B007E; Fri, 19 Jan 2024 02:12:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 01FA16B0085; Fri, 19 Jan 2024 02:12:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E2D306B007D for ; Fri, 19 Jan 2024 02:12:56 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 57EC440C0B for ; Fri, 19 Jan 2024 07:12:56 +0000 (UTC) X-FDA: 81695193552.18.7C4F5E3 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf10.hostedemail.com (Postfix) with ESMTP id 7069FC0016 for ; Fri, 19 Jan 2024 07:12:54 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="O4/soQzz"; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf10.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 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=1705648374; 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=o2rGo4E9Z6Imu0yMI8hCIg6A3l8W17KcdQeDBavO3jI=; b=2hypCN/v1N59M409qyewsQX3JWsK4VBLH8v1njxYoW51BeU5FkI7sAEr3DjcOJGonQ76tq FdQz61o7xK8Fq6OZdtBjSHFILWWOGPGgVUxfoFi/DruPPfY+DfcxxmqCGSiAOy+OUSA0j1 Jh0DWTO4PsUOKgODKutqDj0+KTCkLcA= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=fromorbit-com.20230601.gappssmtp.com header.s=20230601 header.b="O4/soQzz"; dmarc=pass (policy=quarantine) header.from=fromorbit.com; spf=pass (imf10.hostedemail.com: domain of david@fromorbit.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=david@fromorbit.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705648374; a=rsa-sha256; cv=none; b=TJCyNKaCNCVkDMacUMqrDwJhb3KRrDlqPkKJoszOD4AdskbmI4k1mJvTav/7gza/p+B+7H sKyQ8KR0jJEbfO6lPFT7bLNY6PvdPmiHIKBakAKQ9q+45UabLETxgAWuv7cMgCsx5UtKGf pDyNJWslb550incVjriPJkeB3h83CXM= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-6daf9d5f111so520969b3a.0 for ; Thu, 18 Jan 2024 23:12:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20230601.gappssmtp.com; s=20230601; t=1705648373; x=1706253173; 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=o2rGo4E9Z6Imu0yMI8hCIg6A3l8W17KcdQeDBavO3jI=; b=O4/soQzz20J2uwTNLqn1IMsFOzX/qb5H01sQwQFC7dCB4t84qyqqfHAyWfIDqcm7Z7 N1F/BWdmPorPjlEv41a8mZ81/CBSbY9AQM36Sc6LbMnLzHLWjQLForLzLCglT56lmUc+ IV0scBPtor7o/06DtS3mYcfz8ecClx7PUguB0mXY4qVgHqGWIfyh+Sl6VvxqjLpmY2Ol KT3bPf206qVCliwqudPM2AzZKYyUkXoJHn2W/v7puTxBwPdmOE8lMizRuHjKuzejk/lu XvxvEBCUwWpWr0ScD7OUAFSN3ymwsRcQg2Jq1/MHuih1V7XpT16oDATrhpORHGzA9TKD OfiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705648373; x=1706253173; 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=o2rGo4E9Z6Imu0yMI8hCIg6A3l8W17KcdQeDBavO3jI=; b=rFEJkR7Hr1OSoMEzW3xC44ytnCzMGLSOoUK+cOxOP59U/a48bJulkTX4FPNcOQXEAb hTq5yQoKMQ0Slpz+FcBsQQqAocrL09EXUCwcPoZc92j7bnLXjZdBACZp+6nMU3ZkO2MZ wYdvcYqFbcYDksfA7lMWQpmwHIhz7VmAgq1IGY/nipOedXNfk2hbTSnX7iXSkDAKCUst TRGv/RkyEFhkr4WketADLlxtujUCUoVKKFpIwIynMS1RI+oWCzyrox2jU2OYCt47K0t+ HgcrPlBcfxjWiiUpS2Bl9gL4NRCBbWlZ9Yti9vEO9PWvjuxBNLS4Qb6KTjqAf6udcXZm /9NQ== X-Gm-Message-State: AOJu0YzqnIGEMRRg0OWOTvcXD8/Ofn77CK2yF9tQeuG1w/Je/vIczw0O DEP5nzClIp/6fI/2eNYU+45MXq495VjDiuTkbYk70wCwNr11KK26tIdR3lHULD4= X-Google-Smtp-Source: AGHT+IGg02vRJ90ZoWhm6XmrZ6hN65lib3+C3Y9NWWso++OQcw3k7dwytv7T3EhpMSdT0Gz3SaJmMQ== X-Received: by 2002:a62:6381:0:b0:6db:7543:6952 with SMTP id x123-20020a626381000000b006db75436952mr2319535pfb.52.1705648373101; Thu, 18 Jan 2024 23:12:53 -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 u6-20020a056a00124600b006dbc5569599sm339002pfi.10.2024.01.18.23.12.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 18 Jan 2024 23:12:52 -0800 (PST) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1rQj3Z-00CMIL-2t; Fri, 19 Jan 2024 18:12:49 +1100 Date: Fri, 19 Jan 2024 18:12:49 +1100 From: Dave Chinner To: "Darrick J. Wong" Cc: linux-xfs@vger.kernel.org, willy@infradead.org, linux-mm@kvack.org Subject: Re: [PATCH 3/3] xfs: convert buffer cache to use high order folios Message-ID: References: <20240118222216.4131379-1-david@fromorbit.com> <20240118222216.4131379-4-david@fromorbit.com> <20240119013100.GR674499@frogsfrogsfrogs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240119013100.GR674499@frogsfrogsfrogs> X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7069FC0016 X-Stat-Signature: eehm3fp4k73c1innz8wf41kj678tomxo X-HE-Tag: 1705648374-378784 X-HE-Meta: U2FsdGVkX18TY3qywjxng7PpmGI1gHuVjp4ibbaB4iw6VMbTDeLuM9+jDfhVNrXvlFGTdqbXCo3LK46B4uC9+M74NNwwVFHkhb42j2cDI5P9Ggu6aa5zRnYjESwYz8llR9WGbB4lw0Irpecy/nAwAIkVijvQvD3iYrk436VuIhJHHh6DS9Pum5r66A9exS74PeM+k1TgY+5jVWb/T8JKfmLbsKloFyGQ7fdJ+5KgDgdgtk9OEEuGiwcID1pzdozXftiwbP8Sa+rbJN2Q58Lr7VY5CiT3NIUUbb+2jhDY7Ct0J+cZUYpjbtHVfefnpi6Smr+vEp75e4ga5Fw40bw+EdzCoh2rFR5kBOndkvMUI8aMDtGGrjIJM6mWwpd64Au66NVVvr+2Lmg7R1yrwRtGvVoBq9uS3SMvbyIyqZqaPMfkxELOw3qk1JRJKPG+w3Ic94ZDgdaRh/NJGTeMzvRq8oIJXi4f4J5Cu95r2JAvOy3GRMKJOBySsXFoT8dQThkX4mYZAoplaks0r46oHYAyyktz3LLc1YyJ4F+U4cvXxDI/TiQoVSLwWrPQ4ag57QAfQjr6alyLjfpaQA57bd1EcsHQ9kVum2spBjxFnZi71vYvDjPkh5tntI+IakP03Cs2DtwLfxpAVf0hE44NqT912hAjFB+OqRi+JpIRlOLq2WrWf2lrlIDV3LtYJGwBmXm5OHH/nOLm8G6SrfzVsRyACq7wmHZngQvXEzU8Mecna65T782DRqH2Mk+Urzu+QKdgHOL2snNk+k3NRTNctxLLtOxdhmk3J1bw5lJnGaHqVqK0FFxAehJR7UwfoZir0gOmrmYsW7SrZYgw6MoRIVrVJ4izmrrh49lB6jHsoVwSgSPWkKqg33R7kNiy5WabUtm3AETl3ghmPnF6A54h42yzh8cRj6wfApgoGOUeMNICDM8o9Z7J48bmAPnDFoziMKQSU8KqOfBWgEYVrROp/0p kSIx9L+/ /D5HcT1DvPQjiihp2KPQmBktzEwtdTouTXLZzoP0y/dhuQXmvILrILvmigk9vkCZSgqHp8zoxS6136sb+uEARR+MFa40EwGv50tAm+ndWM6GECegu4Ih7HsjTUdPubQXzlBCVC4j/52DO/jOGw4x+rivHKGK2jbIXkHgZl8SCFFD5skpPjGfxS5MXUJj5uclO0/wDYgeQU2OQCPxqxYki8zqVuwj2WnzfRklY3WSa7Ygu+mqsoiTQid38Pdrs2irfd/nD7hLgwowM/oAgLGdY6AGYF3KYAt76f2uSq1ViqSvAsTFdsk8AtRPlfN1BvE2G20WkCaKw1eBMJ9JFfYf1mty0f1E6TEgbWV5dZmiARdrBrT6lcfJk3bKhjzgO3CodSSNtNKd3DMpzARvBPPKqC352wIYj6/Z9V3VZLyKoVuZFRZ204Fvlrb5kbv1xSOLv1yEF21sizYean+bM1ZKWeeH/BhH/YYDwv4r23SOfGJHgtEXPtNEQyoqCbQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, 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:31:00PM -0800, Darrick J. Wong wrote: > On Fri, Jan 19, 2024 at 09:19:41AM +1100, Dave Chinner wrote: > > +/* > > + * Allocating a high order folio makes the assumption that buffers are a > > + * power-of-2 size so that ilog2() returns the exact order needed to fit > > + * the contents of the buffer. Buffer lengths are mostly a power of two, > > + * so this is not an unreasonable approach to take by default. > > + * > > + * The exception here are user xattr data buffers, which can be arbitrarily > > + * sized up to 64kB plus structure metadata. In that case, round up the order. > > + */ > > +static bool > > +xfs_buf_alloc_folio( > > + struct xfs_buf *bp, > > + gfp_t gfp_mask) > > +{ > > + int length = BBTOB(bp->b_length); > > + int order; > > + > > + order = ilog2(length); > > + if ((1 << order) < length) > > + order = ilog2(length - 1) + 1; > > + > > + if (order <= PAGE_SHIFT) > > + order = 0; > > + else > > + order -= PAGE_SHIFT; > > + > > + bp->b_folio_array[0] = folio_alloc(gfp_mask, order); > > + if (!bp->b_folio_array[0]) > > + return false; > > + > > + bp->b_folios = bp->b_folio_array; > > + bp->b_folio_count = 1; > > + bp->b_flags |= _XBF_FOLIOS; > > + return true; > > Hmm. So I guess with this patchset, either we get one multi-page large > folio for the whole buffer, or we fall back to the array of basepage > sized folios? Yes. > /me wonders if the extra flexibility from alloc_folio_bulk_array and a > folioized vm_map_ram would eliminate all this special casing? IMO, no. The basic requirement for a buffer is to provide contiguous memory space unless XBF_UNMAPPED is specified. In the case of contiguous space, we either get a single contiguous range allocated or we have to vmap multiple segments. The moment we can't get a contiguous memory range, we've lost, we're in the slow path and we should just do what we know will reliably work as efficiently as possible. In the case of XBF_UNMAPPED, if we get a single contiguous range we can ignore XBF_UNMAPPED, otherwise we should just do what we know will reliably work as efficiently as possible. Hence I don't think trying to optimise the "we didn't get a contiguous memory allocation for the buffer" case for smaller multi-page folios because it just adds complexity and doesn't provide any real advantage over the PAGE_SIZE allocation path we do now. > Uhoh, lights flickering again and ice crashing off the roof. I better > go before the lights go out again. :( Fun fun! -Dave. -- Dave Chinner david@fromorbit.com