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 6DD44C54FB9 for ; Thu, 16 Nov 2023 22:40:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C87746B0437; Thu, 16 Nov 2023 17:40:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C36A86B0438; Thu, 16 Nov 2023 17:40:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD7A66B0439; Thu, 16 Nov 2023 17:40:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 9A9A96B0437 for ; Thu, 16 Nov 2023 17:40:19 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 50F8B1A06C2 for ; Thu, 16 Nov 2023 22:40:19 +0000 (UTC) X-FDA: 81465287358.29.E5F7CB5 Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by imf15.hostedemail.com (Postfix) with ESMTP id 203DFA0028 for ; Thu, 16 Nov 2023 22:40:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=ttlAA6m+; dmarc=pass (policy=quarantine) header.from=gmx.com; spf=pass (imf15.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.15.18 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700174417; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=NTMjNJBY/xj3vWMBH8apO8JTOGZxMkKAOSxv2pq3mFM=; b=ERTkl+TlBxRKQvpeDKX7YzMWYd2AYQvZ60xLcwfBMT5r7IbiSQfDdaaDzeVrlu4ursrvOW /XXn+4O+4BosGmbTrM8DyHZZ2K+YP7vzczhsMxNjf7VsAKzslfqW/cPZx8njTbj7Iwz1Os JjK3Uay7MSAxwUqqL4c97ROltzY63aA= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=gmx.com header.s=s31663417 header.b=ttlAA6m+; dmarc=pass (policy=quarantine) header.from=gmx.com; spf=pass (imf15.hostedemail.com: domain of quwenruo.btrfs@gmx.com designates 212.227.15.18 as permitted sender) smtp.mailfrom=quwenruo.btrfs@gmx.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700174417; a=rsa-sha256; cv=none; b=MUyt9xgjAH9vSFQxIsX60SLAV+fLf1H5pfC9d+4/DXhK9c4+nYQDvYJz02pSrxSxLjtnMP HV5bcRMrXnjWveUWgQMM3J4u9XbcpQTCYt/sTPkBwPmIfrrcGJZmMrZrfS7s7eret/h3mR S9N6JMRkKiXikXb3S8BaIuitAPHumNI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1700174415; x=1700779215; i=quwenruo.btrfs@gmx.com; bh=FGy/fz1ZDkLXiSf9UT7wedokQxCPJmFYAXb+PdGb614=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From: In-Reply-To; b=ttlAA6m+3OhsravnRnhTbt4BBHPh6tByT/PdtGFerZWueeBm9kSoZNy5nyFKgs2w IAvOESshlFao8E0fdaaJpbBwLtLOMnMD0Z46G3LmgAuyNqcWa+CbX87Yz1rdT2FPO N8EEtPSKpgavu9tItk7UB3chS7iHu/ZiEwcyYp+RliGLG4+aWbFqTlf6+nViRZOwG Iy0kCCe77DEhw2XF/hi4g6lOtUnIcL5aCDwPMLp9iP+fcFnu9LIJWINicf7qzud5q xUl6fr7g6gWrIbN6ULkfSAWCQJ6FfmwA7ns0Yu+OKRSwnggMVhVAtDtdpnz/TuLIr wifFc4g31o4E1nQyFw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [172.16.0.117] ([122.151.37.21]) by mail.gmx.net (mrgmx005 [212.227.17.184]) with ESMTPSA (Nemesis) id 1N7QxL-1rR4ol3LRt-017kjV; Thu, 16 Nov 2023 23:40:15 +0100 Message-ID: <9ecbebd3-4dc1-4560-9616-1af861c376e1@gmx.com> Date: Fri, 17 Nov 2023 09:10:10 +1030 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Mixed page compact code and (higher order) folios for filemap To: Matthew Wilcox Cc: Linux Memory Management List , Linux FS Devel , "linux-btrfs@vger.kernel.org" References: <0e995d32-a984-4b65-b9e3-67fc62cc2596@gmx.com> Content-Language: en-US From: Qu Wenruo Autocrypt: addr=quwenruo.btrfs@gmx.com; keydata= xsBNBFnVga8BCACyhFP3ExcTIuB73jDIBA/vSoYcTyysFQzPvez64TUSCv1SgXEByR7fju3o 8RfaWuHCnkkea5luuTZMqfgTXrun2dqNVYDNOV6RIVrc4YuG20yhC1epnV55fJCThqij0MRL 1NxPKXIlEdHvN0Kov3CtWA+R1iNN0RCeVun7rmOrrjBK573aWC5sgP7YsBOLK79H3tmUtz6b 9Imuj0ZyEsa76Xg9PX9Hn2myKj1hfWGS+5og9Va4hrwQC8ipjXik6NKR5GDV+hOZkktU81G5 gkQtGB9jOAYRs86QG/b7PtIlbd3+pppT0gaS+wvwMs8cuNG+Pu6KO1oC4jgdseFLu7NpABEB AAHNIlF1IFdlbnJ1byA8cXV3ZW5ydW8uYnRyZnNAZ214LmNvbT7CwJQEEwEIAD4CGwMFCwkI BwIGFQgJCgsCBBYCAwECHgECF4AWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCY00iVQUJDToH pgAKCRDCPZHzoSX+qNKACACkjDLzCvcFuDlgqCiS4ajHAo6twGra3uGgY2klo3S4JespWifr BLPPak74oOShqNZ8yWzB1Bkz1u93Ifx3c3H0r2vLWrImoP5eQdymVqMWmDAq+sV1Koyt8gXQ XPD2jQCrfR9nUuV1F3Z4Lgo+6I5LjuXBVEayFdz/VYK63+YLEAlSowCF72Lkz06TmaI0XMyj jgRNGM2MRgfxbprCcsgUypaDfmhY2nrhIzPUICURfp9t/65+/PLlV4nYs+DtSwPyNjkPX72+ LdyIdY+BqS8cZbPG5spCyJIlZonADojLDYQq4QnufARU51zyVjzTXMg5gAttDZwTH+8LbNI4 mm2YzsBNBFnVga8BCACqU+th4Esy/c8BnvliFAjAfpzhI1wH76FD1MJPmAhA3DnX5JDORcga CbPEwhLj1xlwTgpeT+QfDmGJ5B5BlrrQFZVE1fChEjiJvyiSAO4yQPkrPVYTI7Xj34FnscPj /IrRUUka68MlHxPtFnAHr25VIuOS41lmYKYNwPNLRz9Ik6DmeTG3WJO2BQRNvXA0pXrJH1fN GSsRb+pKEKHKtL1803x71zQxCwLh+zLP1iXHVM5j8gX9zqupigQR/Cel2XPS44zWcDW8r7B0 q1eW4Jrv0x19p4P923voqn+joIAostyNTUjCeSrUdKth9jcdlam9X2DziA/DHDFfS5eq4fEv ABEBAAHCwHwEGAEIACYCGwwWIQQt33LlpaVbqJ2qQuHCPZHzoSX+qAUCY00ibgUJDToHvwAK CRDCPZHzoSX+qK6vB/9yyZlsS+ijtsvwYDjGA2WhVhN07Xa5SBBvGCAycyGGzSMkOJcOtUUf tD+ADyrLbLuVSfRN1ke738UojphwkSFj4t9scG5A+U8GgOZtrlYOsY2+cG3R5vjoXUgXMP37 INfWh0KbJodf0G48xouesn08cbfUdlphSMXujCA8y5TcNyRuNv2q5Nizl8sKhUZzh4BascoK DChBuznBsucCTAGrwPgG4/ul6HnWE8DipMKvkV9ob1xJS2W4WJRPp6QdVrBWJ9cCdtpR6GbL iQi22uZXoSPv/0oUrGU+U5X4IvdnvT+8viPzszL5wXswJZfqfy8tmHM85yjObVdIG6AlnrrD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:Tq3Qxc3YvvFvSyvyR/z7cbLil6IhBzrFgVyBtOH688XkOmWyOjx n11U7xp1SGI/Yztaox0Z9+5+E77KDHXey1uZa9jedjCcOzc2KrBZa9FbyaK3W2fQVBhjlV9 A/INiw+roVbn93J195vCFYA5qZaqJFiLifnT/4HSpqHNHVMchB4x5CNiUAw+PFEDvzYs2O/ KQt/Yno/YLWPzeX7iifqA== UI-OutboundReport: notjunk:1;M01:P0:3wwVXDwrmBA=;eD0D8eD93cbTgSigLGckCaESnYS AYDgzIx5czNE8cEigmjRc4+Bkwzfv5gO50AiEl8xqRXl8AaSYZIujtdjcbp1me22FeYiR+sO3 NKuBH7SbMcwjLGnHU89eRHtSX531Zq4v/poKfotWlBEKLDHNGO0kR6qiS8UYQfn6rEh2EgsTG WTUKMNIbWkD/vwV1Kpk04i8eJagLBhc7AMAxJEosQWr4S8emeFe4R9Wct1JLWZdGiIoNAwcJe q9FEMuFszwJ4vDiCdHHyPp8iV9i3ej1AgN9tY85wSjUIJxUZ01RVfUIhWC5faT4En7eM2JkwT 7V3Nri+0i6BGKsQuVXcp/1ZGRCdC5+i9i3wNTXmSuVjTEmTA95DUUdpQNMGsdA7+6hxH1ufAT H1SjiSwZJqusx6j7ujVTZPiZDLUKsbY0M2FSdMg508nY5WF8LdrYG6aNGOH8QG7Fd/ZYSpoH0 Txjipu1/KrMZv7EOpg7DBT31QLWyqlaA3sl5YEWU8OvoCPdzlBmFhwaAIVG+fNudwCLlSfrgY bFOYZRUN1JNXFjyeqSjVakEW8A9fkXE+69Fpr7NLGlNyOKUnJH9j2CfMWhxUDEnwmBcieOiYH +A2sZq4wniI212JU/GfV9uuype2KeSo3rt6eMKZZnqi8JRGBxIuAsE4kcWNtkLJ4e628FYY/T zziJUwIshBiqvFa36BMsC/lQLJ67vXGnC4cJDnRSJgcWuDPKLHO7lZ0aa0DFzvUR4bB6D0nTz HECwlKrUZNJfDZZ6t7ydXs+aw7zcv3hoOExX2Alnry2XtYR6VAAPZJajXiQVrWph7GqXCzYku olE52gx9y23MD002XpouMVHrRbbbZ12cp+tNbglDgMB2Q3N9fQr6FAl8/s7INZ/LhF7iGm0sj h90Ve/Xv4sqADT9MkVPSMZewVKjIunjB2EsTIVMAMh6jBaXbfTD36D9yImd9Zo6s8V5NPSLNM qoAX+Q== X-Rspamd-Queue-Id: 203DFA0028 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 7sw4qrjtkytfdk966a8m4k74e69ueg1e X-HE-Tag: 1700174416-682975 X-HE-Meta: U2FsdGVkX1/qKOXAI8FP1+eXK1FgwtY8pfFjzL5qtn2odqFye1131xSOOXEFnswB7s43+jvkdRhlroX0jVEccj/XahApUPbHyffHSGZyS73u6REM41HkYbG6RQNrz1gC8YmqIZxakc18MiVL7799wAqHD+nk7GqTZ7BhNnrRacKgq5q7RhaNDfBVxFBBs49cs1BmmbX4w9SiTaKRHdG71S+V9/vbslM0bO19pbZzCcbj92lJMUWZV4MD5xJzh8m0GNZhMgsseGcm3CtXX3XrdhPrIn8c7nyP9QP72HxXN7+tlSlQ3QdQq0ZavOkTjHn3VpIWhRoqgf/lGhw1unLLpab23MtUze+GrdzPOGSZDSxhBBgrDXtnp2oKFhNyZrd8sRUm2bVTdYfj3kt1GR7Inhrxh1aO8ynOZzyby1ecpM6YWdlOpLmC8x3DxcksZlkb5m1L4yeGq/xBsw0qQYzdxDrvTPH3zQXrSrero7uK99bG1odqnHFpIFR1ayXbtPCWznX9qc39BiHmU6YoFYNB9sH90pxa3mZQERrMD+1e4HoqvDy/qNWv8rZqayzNlZ1uFF0NQT/I8/kSz/Qp++r52uRtXO3s78xv+dBdPgX5di0h77FY8UcRD5atqah0z/4V8pWm+q0N+Lu9qbDusvHYqP7c5DgON5avjo9fYMwu7aIlsC2peYJLpFZ5Xug8kyMZn5uW3LlmihmWq5Nm8UIyZ3GGLsf506xlfRVTssLYI7wZ9BhuryMKUrW51lln7S8CZo5D1WxMvjWViBc9JQKIZVxJ2JrWl1UlIiVEGAKR7u8ReFn2hzm82J2Fq0PH2SR7eDmbYnIbdy+pW5WrDNZdhz05Bq1lQ1kuB/LPrveVAr7PlZ1DhktCGEzeVnUMehNHSIUan+NxLwkyzEyOUdpefzuQDzmEThHMEZYKgTCCrSpTy9xEddUqNak/crJsR0zBMmNo61jwkWucOgevvRz GSoXpO8v xu7OdmWtfmj+bPUFWarIaJ7rvI5Oz1XofaZkjKCjLlnSdWSIm3To67/7Gpjlz0xLjy3LaQPx2Tgu6MnxlPrVRiP20dhB+nlcCQ4mEG/cKxSQche3xKz7KQg78R4YYc3DHVt8ladqyYW9b32sVNRFlnGdH4UI007rbEECaom76qyF7Rx86aQ7UePa/CmkNWwo/56Oe5gEz/CT6C3dV/mEywad4QiZSLvJoR6R7ELsbOZtDPi33i/chhFkHgCt674pGMlRbek2bHA0FlUJREu3zdLKN5c/qWQZnVQZ1s70vaJKVInQ0ueYi4Y9q50kbpaJGL3rWmmHvTizWXZMAYj9zJPG5wIVM52VWd1V2zQgh8bSOv7MUXjdGrGmkD0i7prVGi2VntqD3QFoyO1PHsFOozLerlw== 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 2023/11/17 00:53, Matthew Wilcox wrote: > 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 f= olio. >>>> >>>> I believe the regular IO is totally fine, but what would happen for t= he >>>> 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 th= ing >>> (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 i= t). >> >> 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 fo= r >> 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. Just another question. What about flags like PageDirty? Are they synced with folio? The declaration goes PF_HEAD for policy, thus for order 0 it makes no difference, but for higher order folios, we should switch to pure folio based operations other than mixing page and folios? Thanks, Qu > > The GFP_NOFAIL warning is: > > WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1)); > >