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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 08B50EB64DA for ; Fri, 16 Jun 2023 22:40:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232916AbjFPWkP (ORCPT ); Fri, 16 Jun 2023 18:40:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35334 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232695AbjFPWkN (ORCPT ); Fri, 16 Jun 2023 18:40:13 -0400 Received: from mail-ot1-x330.google.com (mail-ot1-x330.google.com [IPv6:2607:f8b0:4864:20::330]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6702D30F8 for ; Fri, 16 Jun 2023 15:40:12 -0700 (PDT) Received: by mail-ot1-x330.google.com with SMTP id 46e09a7af769-6b44b5adfd3so914208a34.3 for ; Fri, 16 Jun 2023 15:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fromorbit-com.20221208.gappssmtp.com; s=20221208; t=1686955211; x=1689547211; 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=eewBVDe5nNaSM8dqadQLKOlfMcQrNasJb6oD7oBFQEQ=; b=yLrgJ99p9qAqQys+W37noyN5JmKqgwDiiXsqJ7W3WKnxgFxaGJ8xqpnq3KJA5VuECG ISMC49kXDH1TMP8r+9kvepi5TOHJzElrK7adriCF4T97Q+0wzyG3lAU0sStnF1sV3hZV eQItJbyiN4wcTFyc6uwqTwQ85BgrRS2K9eVxnhyBboZgF0K6vJ5Lo/Lfw966X3hlBwNs mZB7U61oVMnWSV4MqTxQcvES6lFIaC4xSWPStZCWLoCRpwYhbjNyEjoVPa3WcIDgRfc4 tFN7DL9I45R7fSTc3aX3G0wK6Tm9BElXVmRwAjkWtirXq+f8n4NaCx38kMpbwXkjlRGf 4A6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686955211; x=1689547211; 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=eewBVDe5nNaSM8dqadQLKOlfMcQrNasJb6oD7oBFQEQ=; b=PivElCVYKuOk/F52IqZ433sV21HsBuo/4stkyFBLlZ8zR70b5c0IymB7LhWwDMjo51 a3HeIPMxGg1D/fsOuqi6eBT04aNULtcsx97IuzVQ3NZBLriA3J2u2tKPTaPT6MMHeH4V i7iCx0PHu4nBGE38tLy8X+N0PZbuC6VZJbjLCcDmalIwrOLouhx1wgQflUE6q2hWc0hj TKkrUUgyy6eSW2HhUrGL+g7lGmKge0TNfMuZJfq3VdC5DPVa/mf9L0jCbeeMO+WWnwzN zgxh/4YAxlmiUTQLiASo4RwFxjQROmg+Ubvx2LmnmOmrzYPeYdSm/8xFke99l5qiF6Jj iVTw== X-Gm-Message-State: AC+VfDy7H6+usYyzNZsyQe2pUa+U70EpYi7aTFeQB2tSZmSjrp1FUSF0 G0zJdVZjAli615VMyrSmBKtWLA== X-Google-Smtp-Source: ACHHUZ7AZ8wn+x1kFKZKUqhmT/4coujbqi6Q5vEhyuvPN9oOMO8Tz6/cDPwzj7fGJ7HceKMbb5xx9Q== X-Received: by 2002:a05:6358:e816:b0:12b:eac7:fd7b with SMTP id gi22-20020a056358e81600b0012beac7fd7bmr500416rwb.17.1686955211305; Fri, 16 Jun 2023 15:40:11 -0700 (PDT) Received: from dread.disaster.area (pa49-180-13-202.pa.nsw.optusnet.com.au. [49.180.13.202]) by smtp.gmail.com with ESMTPSA id a15-20020a62e20f000000b00666777bda00sm4177438pfi.110.2023.06.16.15.40.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Jun 2023 15:40:10 -0700 (PDT) Received: from dave by dread.disaster.area with local (Exim 4.96) (envelope-from ) id 1qAI6x-00Cdf2-0g; Sat, 17 Jun 2023 08:40:07 +1000 Date: Sat, 17 Jun 2023 08:40:07 +1000 From: Dave Chinner To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, linux-xfs@vger.kernel.org, Wang Yugui , Christoph Hellwig , "Darrick J . Wong" Subject: Re: [PATCH v3 6/8] filemap: Allow __filemap_get_folio to allocate large folios Message-ID: References: <20230612203910.724378-1-willy@infradead.org> <20230612203910.724378-7-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Fri, Jun 16, 2023 at 06:45:43PM +0100, Matthew Wilcox wrote: > On Tue, Jun 13, 2023 at 05:54:35PM +1000, Dave Chinner wrote: > > If I hadn't looked at the code closely and saw a trace with this > > sort of behaviour (i.e. I understood large folios were in use, > > but not exactly how they worked), I'd be very surprised to see a > > weird repeated pattern of varying folio sizes. I'd probably think > > it was a bug in the implementation.... > > > > > I'd prefer the low-risk approach for now; we can change it later! > > > > That's fine by me - just document the limitations and expected > > behaviour in the code rather than expect people to have to discover > > this behaviour for themselves. > > How about this? > > +++ b/include/linux/pagemap.h > @@ -548,6 +548,17 @@ typedef unsigned int __bitwise fgf_t; > > #define FGP_WRITEBEGIN (FGP_LOCK | FGP_WRITE | FGP_CREAT | FGP_STABLE) > > +/** > + * fgf_set_order - Encode a length in the fgf_t flags. > + * @size: The suggested size of the folio to create. > + * > + * The caller of __filemap_get_folio() can use this to suggest a preferred > + * size for the folio that is created. If there is already a folio at > + * the index, it will be returned, no matter what its size. If a folio > + * is freshly created, it may be of a different size than requested > + * due to alignment constraints, memory pressure, or the presence of > + * other folios at nearby indices. > + */ > static inline fgf_t fgf_set_order(size_t size) > { > unsigned int shift = ilog2(size); Yup, I'm happy with that - "preferred size" is a good way of describing the best effort attempt it makes.... Cheers, Dave. -- Dave Chinner david@fromorbit.com