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 4EF4AC54FB9 for ; Thu, 16 Nov 2023 14:23:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A97E26B0470; Thu, 16 Nov 2023 09:23:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A46956B0472; Thu, 16 Nov 2023 09:23:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90E7D6B0473; Thu, 16 Nov 2023 09:23:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 81E266B0470 for ; Thu, 16 Nov 2023 09:23:56 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 5E17CC0A0B for ; Thu, 16 Nov 2023 14:23:56 +0000 (UTC) X-FDA: 81464036472.08.912B297 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id AA006140021 for ; Thu, 16 Nov 2023 14:23:52 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=DYS5m2HL; dmarc=none; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700144634; a=rsa-sha256; cv=none; b=rpFQTMTkwgMXcBZ04klcscRCD9bThud6/bzTHlAOD+jXeCXrkWRN9ZpD8hqg+no33nK/Ah D+hFHfkxKD4zgsCYF5myA1UNTD6S+GWwlmosFVvnvpsoG2W56DcFbBQmV00XP4OYwwPoGn HKXvFShWfoXVoYb7kYrmeSpnGeV4/Ro= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=DYS5m2HL; dmarc=none; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700144634; 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=dgZYG76MUgPHX67tQhnkUTmVuk0UMwkw1IreH1RBeME=; b=k8pCEB15H/YSNLyhPaVTLuhc4SHSR4WRHnJT8cow3vw/8bpSQN6dUgUgsCi6xVC5FnP7t3 lpzVvKghqfEfd/nYb88QTw4RkgvcAFiyl6iLQlyfmoJQYwbVB55st7qK0hz8tplesWsiS/ qK1gdWrWlw4cjZ2dHf9e8Ctd0uknRI0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.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; bh=dgZYG76MUgPHX67tQhnkUTmVuk0UMwkw1IreH1RBeME=; b=DYS5m2HLHoY//Tuy5RMME89zll oXwSQYYlbXkvfFm2iQ/PoV3DrK+KxyjHJp9qSez3cEJDNrFkpzzliOw11VIdnyVPAYna1DAN8ovoy RVPskZbnE8TRDtt1ptf80glV4/0kDKIolfhVvU8q2ilfPg75Fu3l1Z/JmDkv06cod7YM1lcu3Fsa3 2X4DBQumiAoky4S8QPU4HW1/2reoxLoV6t9Ec1qmzA0sDlhpCV/tOfNBm/WDD96H4SyUQvXEuZPeB jMkzrbdzBTGsqmojF8EgYM/lrlpnW83VXsT7Y9eeSYBAT371cxUOl6OwbWdonZatCw4vugfRr6gTT JHI8nVSQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1r3dHY-003SWQ-0b; Thu, 16 Nov 2023 14:23:48 +0000 Date: Thu, 16 Nov 2023 14:23:47 +0000 From: Matthew Wilcox To: Qu Wenruo Cc: Linux Memory Management List , Linux FS Devel , "linux-btrfs@vger.kernel.org" Subject: Re: Mixed page compact code and (higher order) folios for filemap Message-ID: References: <0e995d32-a984-4b65-b9e3-67fc62cc2596@gmx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0e995d32-a984-4b65-b9e3-67fc62cc2596@gmx.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: AA006140021 X-Stat-Signature: 7pk5xsx5n54ra87h55op6ocn58h1ccwo X-HE-Tag: 1700144632-814959 X-HE-Meta: U2FsdGVkX1/kr3Yj5lcU4TLSLEXjwK9Z6TEUfmKAme/atR27BzWh8Oyt4EF74RX5m2w8thyteu6A5Lkee1Lom2RuKkynLGfEMVKDDDH/ZBuRM18GxbvmyumUY7wwBph94gzG1fH3oxvyWh/BJhIkZVfgUClMIx6Fd1o2ubrZDUlDzD2cdjjzXws1DIxqysFnDY+bDXHUBkPQr1uVkGXKKAjP9ebspryZIJH6a6j8GP6tVW1aV6zOo2I9b38EIoKtsNbs3Aqyek9XA7yW1xwsf4YANVeUpi5huLo+P0xISmyQcTpijduQZGFHw33em6sVCVMA87eaabXt9Uj/VVKXZ+VqVGgBqNb6AHtWd+Al1eVKLlFKz88Di12w+7nBTF6dttpFvhbXvlr8l6HIRL1QiqfFhOv8DGSpr1XFVKjUHLCIkPsT8F4N2ds3R11EAm3ERjgdDpg1LN+snK4e+9l2xeKou132pAPkDCd6acoQyMTNouzOefkLGI2eo6LF2nElBMoL7e0TEP3TLD3T7kljFOKUeY/JNlFLz4flL6yYIiwSKEfFRfSTf2T+/hy40EJHSpjOmif/81XQ7AvrsCk+l8+Kd6Ggww1fFuV9YNR/ct2wI+gyx53l5nY0Z/Frf8vvZLzu3etD0g2fQwCVrKvO/M/n5bT/0R8Fi/Q3E6GfGQG+BynVGoyXTNztbb5y+pOz+Hvvt0PMDiwGRFqiTSDVwOWu3ewNRmKKV5sdlq4RtRRAvaRTgI1pMIORt8ys5BLkgNhN1PV3XDcmjKYW75qL2bIxlouKjC0zfzTCLwWmztXJ52ui9rNqOcwAil5616AxFpvWkho7nPzjKvLcN3PrHx2XuwnsLe61smNa4swFaAoAIQDdz+f0yvTiKMAH4vcYJUL4MBIt8CZOpDd2X4NQo2XsaJQheZoRr5R9bJ7bfKj8Lz1XoprjhiwJzOAVURbvVFZ5ZBq/2hMqFt+y29Y mpy8Fg24 EHd3m0dWcj/MhaZd+H0aqJFt935vuEVN0qYHmeRB/4sCveVlfbL4jj7gnwspBTQFpHT035L79fSNuBsM29XxxNH9NKGRYM90XQETtpuSob684gDYLljXZWmV76EuH3JCjsLpde4WArXZ/kUQhJsdh4Ox65mSq12Md4URyQdNBiNGgIN9LoTA8kgD9QA== 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, Nov 16, 2023 at 04:00:40PM +1030, Qu Wenruo wrote: > On 2023/11/16 15:35, Matthew Wilcox wrote: > > On Thu, Nov 16, 2023 at 02:11:00PM +1030, Qu Wenruo wrote: > > > E.g. if I allocated a folio with order 2, attached some private data to > > > the folio, then call filemap_add_folio(). > > > > > > Later some one called find_lock_page() and hit the 2nd page of that folio. > > > > > > I believe the regular IO is totally fine, but what would happen for the > > > page->private of that folio? > > > Would them all share the same value of the folio_attach_private()? Or > > > some different values? > > > > Well, there's no magic ... > > > > If you call find_lock_page(), you get back the precise page. If you > > call page_folio() on that page, you get back the folio that you stored. > > If you then dereference folio->private, you get the pointer that you > > passed to folio_attach_private(). > > > > If you dereference page->private, *that is a bug*. You might get > > NULL, you might get garbage. Just like dereferencing page->index or > > page->mapping on tail pages. page_private() will also do the wrong thing > > (we could fix that to embed a call to page_folio() ... it hasn't been > > necessary before now, but if it'll help convert btrfs, then let's do it). > > That would be great. The biggest problem I'm hitting so far is the page > cache for metadata. > > We're using __GFP_NOFAIL for the current per-page allocation, but IIRC > __GFP_NOFAIL is ignored for higher order (>2 ?) folio allocation. > And we may want that per-page allocation as the last resort effort > allocation anyway. > > Thus I'm checking if there is something we can do here. > > But I guess we can always go folio_private() instead as a workaround for > now? I don't understand enough about what you're doing to offer useful advice. Is this for bs>PS or is it arbitrary large folios for better performance? If the latter, you can always fall back to order-0 folios. If the former, well, we need to adjust a few things anyway to handle filesystems with a minimum order ... In general, you should be using folio_private(). page->private and page_private() will be removed eventually. The GFP_NOFAIL warning is: WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));