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 2B479C27C4F for ; Wed, 26 Jun 2024 23:48:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9BCB76B0085; Wed, 26 Jun 2024 19:48:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 96BFF6B0088; Wed, 26 Jun 2024 19:48:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 797486B0089; Wed, 26 Jun 2024 19:48:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 5C0856B0085 for ; Wed, 26 Jun 2024 19:48:43 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id C7FA2C173A for ; Wed, 26 Jun 2024 23:48:42 +0000 (UTC) X-FDA: 82274682084.26.B49826B Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf11.hostedemail.com (Postfix) with ESMTP id 8B04B40013 for ; Wed, 26 Jun 2024 23:48:40 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="L4j0+/AH"; spf=pass (imf11.hostedemail.com: domain of gshan@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=gshan@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719445705; 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=d7CqT7ZoVZ21vEmREjMyead0YkkLsWeh8E80zva5ToM=; b=UBsaZj5zcnuHFoKMr+qqvUL96sciTFNcbmGiXeYBF/y6Izm5eeLk0tThQbv+qN2m1uUiuU pUvl1hAm43rtWyxbOBxz4bMhns5vmvmxh4yCzJfl/NuzA3BalIsatnH5xXUPG0VCw4Hod+ f4tNrDvvWawhwdanmInRGbpd4UTAlKk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719445705; a=rsa-sha256; cv=none; b=HFxzdGHsYcPqkCDOmws8zSrvgQI3Aw367Meiq4/5MrBmLIW2vsS6hV6/K95q2T2KJYb81O NHoIgkXj6rHd9sqaS6lWNbvVdBOk0rENHbbYhe+ePX7eaDH1L8hTDCfGzehhoGvqLLdP71 jD3GvD0xibIXBofNe2Bo7OliGLyfQ6k= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="L4j0+/AH"; spf=pass (imf11.hostedemail.com: domain of gshan@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=gshan@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1719445719; h=from:from: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; bh=d7CqT7ZoVZ21vEmREjMyead0YkkLsWeh8E80zva5ToM=; b=L4j0+/AHaWZB4Z3OZmRpTl+yuPwbz5UsruQH6RwEbeClPqeTGSg9KwCClJjThRQfZOPjEO arep7SG5nEvD/qnMWMeqT0mSPuR+okM2HEK983ELNLT1XX18s2MU72HWQszQhknC2uHYJh ETzZktq9zOLgGJldVmP9lqjT1LUubXY= Received: from mail-pg1-f197.google.com (mail-pg1-f197.google.com [209.85.215.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-267-OZg9yTXuOy-ulI7c9KI2Mw-1; Wed, 26 Jun 2024 19:48:38 -0400 X-MC-Unique: OZg9yTXuOy-ulI7c9KI2Mw-1 Received: by mail-pg1-f197.google.com with SMTP id 41be03b00d2f7-7225d0435a9so2705548a12.2 for ; Wed, 26 Jun 2024 16:48:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719445717; x=1720050517; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=d7CqT7ZoVZ21vEmREjMyead0YkkLsWeh8E80zva5ToM=; b=jW6hEcqDIkwXzcDoigxBIljY0gye4t8EeaRlrMFRUgG2fNPikYcWIxSQhFfhbfdm/e 0Fa87/suc4GwE56hQkQLqOsSAusDNuPl9f/5dSOnCH/1+B+sKpy2ZEE/rCgn5Es5QREH 6dpf1r05OLFv8aFPAql8QC3WSoUpGPgJLmnexM7vay6j1Rg060sXP61ppy6NZmDISLsX WiRWoVpobwFq6lbILKD8ZCoUFQInygYG9mGKB8kAq6MtI4opQ4H1NsOmQZZKMoQ3KFpT BkVYY9ywljXdhhl3/0f96xfX3ZfIf5DShPRjjmiLSp5TYzoONQdYr3N3J/qC78SP9EDf s9SA== X-Forwarded-Encrypted: i=1; AJvYcCUe9JK+VsWWIwQoSwSWh3dHqEUdb5kCqDYWy2tuHEGXDCsI8Q70JbOjgPP36QykD9Z1KKMXfZvf1yNpOIzqur0Vkbo= X-Gm-Message-State: AOJu0Yyn85yUwwzo72Id43A8Iz1pVwxi0o06UltZ5Ft0T9Bwpvvmi0NC OoO+ucxq3W8NnCzJ3Rb/3yZWZKsOxxN+BtcDOmdCWBRJl89rrcze6MrWWks+XeL5EC1efLBQini KE3zEXtoPOIZSa3ol+67GI0ieeCHJAnSTxmO8Crxki4JitcmN X-Received: by 2002:a05:6a20:4c82:b0:1bd:1fb9:37be with SMTP id adf61e73a8af0-1bd1fb94724mr5339535637.34.1719445717480; Wed, 26 Jun 2024 16:48:37 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGO4cQmMl+Yz/ePmJozmWEc69fVJbFIuXB/kxX5f4SOa9YmR96mVVLdgm1KF4X5QUEcUDF8Mw== X-Received: by 2002:a05:6a20:4c82:b0:1bd:1fb9:37be with SMTP id adf61e73a8af0-1bd1fb94724mr5339527637.34.1719445717109; Wed, 26 Jun 2024 16:48:37 -0700 (PDT) Received: from [192.168.68.51] ([103.210.27.92]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-2c8d8060f14sm2269364a91.29.2024.06.26.16.48.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Jun 2024 16:48:36 -0700 (PDT) Message-ID: <471488ec-ea1f-4c57-ad0d-bea422863574@redhat.com> Date: Thu, 27 Jun 2024 09:48:30 +1000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 0/4] mm/filemap: Limit page cache size to that supported by xarray To: Matthew Wilcox Cc: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, djwong@kernel.org, hughd@google.com, torvalds@linux-foundation.org, zhenyzha@redhat.com, shan.gavin@gmail.com References: <20240625090646.1194644-1-gshan@redhat.com> <20240625113720.a2fa982b5cb220b1068e5177@linux-foundation.org> <33d9e4b3-4455-4431-81dc-e621cf383c22@redhat.com> <20240625115855.eb7b9369c0ddd74d6d96c51e@linux-foundation.org> <4b05bdae-22e8-4906-b255-5edd381b3d21@redhat.com> From: Gavin Shan In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8B04B40013 X-Stat-Signature: jr5f8rxwxwbm7jkh1n7p4s7ezmix7g8m X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1719445720-708838 X-HE-Meta: U2FsdGVkX1/gBbFlZqSASfVdcyltJA7Q3rQ/fQc4kOS20pcFvfe8348mULM0QKsZ0C/Mrr6ztEjXc5UrQniWTNki6u9W08dHqxQtNahl62RAcCYJ97XMg2V7AaaqdkPYbcqZXGm+YOs0ZuyfvfeMt7MV2oyX5Nn0xCc1BxwIVfI1QUiSzgMjdcA8PgSu9BdU7NI6CT9f2QuTgyxXQTE5pa6ezbMSwQ2BeTQGk6LBzl0OqWhIPZa1LUVgTwT/ctn23i/iZ7lZMOEaxzQILPAeLm+BZL56mI9/NThkvfcfgRz9xuPb4oSHT15VaW8bQ8p3E9+alF495AiTpCuDRAXOIAdfHqeviD7OV240D+4/nmkgMChRS9S5CZYWkUWqCCyS3r/ROx00ERcRqBVXX/cO7g30MDMrhotamego3JK2530c68nbrqyYreJiUtLyNEU1B4JDifF+gxiGe/lOJtcJvrhg4PswwiLoY9ek6qTkg4e7F31atr+1J2YBs9ihO8lTNbs9owQWmdJjJQaYiD/m8o9bAnJmDudVQRw2raPB7zjRkajtyKh/vzbQL7pDOEXlFAUPppTBsllso8tEZvQ3/y+2+KmWtwSx92flmIpbB4nRVQdxz9M9VeJd8GGvoAa2mbiTzpB7ACwOTj/gvrZ/V3EEg+4PNHyDs/FQVfQcq/x8WuvKjiSRQ8tu3LbeD/lZ4N5ZqADvreMy1Fu/pDZLtzLA7lSLoevXMsNWIKihE//tYPtRR1/Ol6DIiqdNFyZPFcK+LxGh0hhu5/XeCuGGmAmSdrmRoAsqI+jq0KofBkkcP7DH7fvGu8/IvZoQBZGCbcLuIVgMKDpXyZ1nH2abJPJm5NeBbWW5gfUWni0NO3PZN9s0FI6jZiLsHKzgpCJ4kH48L+VQJ/5MQs5Tk5wSMr57x1ZDFL9psU4OhSYHPwKTy4NC9MTgauUn0u1YHnOJdxJJiKtHtz3EcoLOmx8 ieAMyYI1 y/voMEwD8zzItxL8pPUsI6XMYFKmAy3vqEi4mhyD4wRbLfUV7sxRQoFq8I7/p5vajD8YFxNupGdn3liPuhhzN7oUsTG7wVaUYHXV0ey4zsj452ZU8CJB7nvUrlS3jbFX9o3YFT5ZcY4EnFA4pfE4rJ4Hn64BI0RSiBXzb0LXH/1uVggusRR7ZFCQahKDL0kR67IwUJyxbQU5HIqLFILZTYi1fiLXf1aD5+RWhHbeEYx9sFiUpLkcaSibCk88EnnZQF8pH3Sr3zPchaJzMT+vb6GJi14WzaHMcO2MOB4yB0kQsRv7dy0EDnwzso6mV6gXKRa5q6q67hgxNje7AjK2QTAUfzKCGH0W1NkgZ0yIN3S1g3DMRTk4ykgRF064fAkgqiy4B+rZOPea/vatX5ll/dHIqZ7FOj8+uxKKQQRhUdZzyjvqxSkr6t79fxjnxWWxH5r0SN/VMI05zfp2NUURm0nLMD8iwAk1uIQyu6icb6pcJGGal57tv2/u8wgKx5IlGYM9ld7wlVgrMLgO+hYVbUZnDU+yCI+yDbLlP0/k0oq00rNS1CsZ4kO3eDP8xdquqOb61zJ/TaCw+zbP+Rk9+GpeJfG6KNMof5mzL7nN/BfvGols= 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 6/27/24 6:54 AM, Matthew Wilcox wrote: > On Wed, Jun 26, 2024 at 10:37:00AM +1000, Gavin Shan wrote: >> On 6/26/24 5:05 AM, David Hildenbrand wrote: >>> On 25.06.24 20:58, Andrew Morton wrote: >>>> On Tue, 25 Jun 2024 20:51:13 +0200 David Hildenbrand wrote: >>>> >>>>>> I could split them and feed 1&2 into 6.10-rcX and 3&4 into 6.11-rc1.  A >>>>>> problem with this approach is that we're putting a basically untested >>>>>> combination into -stable: 1&2 might have bugs which were accidentally >>>>>> fixed in 3&4.  A way to avoid this is to add cc:stable to all four >>>>>> patches. >>>>>> >>>>>> What are your thoughts on this matter? >>>>> >>>>> Especially 4 should also be CC stable, so likely we should just do it >>>>> for all of them. >>>> >>>> Fine.  A Fixes: for 3 & 4 would be good.  Otherwise we're potentially >>>> asking for those to be backported further than 1 & 2, which seems >>>> wrong. >>> >>> 4 is shmem fix, which likely dates back a bit longer. >>> >>>> >>>> Then again, by having different Fixes: in the various patches we're >>>> suggesting that people split the patch series apart as they slot things >>>> into the indicated places.  In other words, it's not a patch series at >>>> all - it's a sprinkle of independent fixes.  Are we OK thinking of it >>>> in that fashion? >>> >>> The common themes is "pagecache cannot handle > order-11", #1-3 tackle "ordinary" file THP, #4 tackles shmem THP. >>> >>> So I'm not sure we should be splitting it apart. It's just that shmem THP arrived before file THP :) >>> >> >> I rechecked the history, it's a bit hard to have precise fix tag for PATCH[4]. >> Please let me know if you have a better one for PATCH[4]. >> >> #4 >> Fixes: 800d8c63b2e9 ("shmem: add huge pages support") >> Cc: stable@kernel.org # v4.10+ >> Fixes: 552446a41661 ("shmem: Convert shmem_add_to_page_cache to XArray") >> Cc: stable@kernel.org # v4.20+ >> #3 >> Fixes: 793917d997df ("mm/readahead: Add large folio readahead") >> Cc: stable@kernel.org # v5.18+ >> #2 >> Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") >> Cc: stable@kernel.org # v5.18+ >> #1 >> Fixes: 793917d997df ("mm/readahead: Add large folio readahead") >> Cc: stable@kernel.org # v5.18+ > > I actually think it's this: > > commit 6b24ca4a1a8d > Author: Matthew Wilcox (Oracle) > Date: Sat Jun 27 22:19:08 2020 -0400 > > mm: Use multi-index entries in the page cache > > We currently store large folios as 2^N consecutive entries. While this > consumes rather more memory than necessary, it also turns out to be buggy. > A writeback operation which starts within a tail page of a dirty folio will > not write back the folio as the xarray's dirty bit is only set on the > head index. With multi-index entries, the dirty bit will be found no > matter where in the folio the operation starts. > > This does end up simplifying the page cache slightly, although not as > much as I had hoped. > > Signed-off-by: Matthew Wilcox (Oracle) > Reviewed-by: William Kucharski > > Before this, we could split an arbitrary size folio to order 0. After > it, we're limited to whatever the xarray allows us to split. > Thanks, PATCH[4]'s fix tag will point to 6b24ca4a1a8d ("mm: Use multi-index entries in the page cache"), which was merged to v5.17. The fix tags for other patches are correct Thanks, Gavin