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 B3E96C001DE for ; Thu, 10 Aug 2023 10:48:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 41A636B0071; Thu, 10 Aug 2023 06:48:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CABC6B0074; Thu, 10 Aug 2023 06:48:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BA776B0075; Thu, 10 Aug 2023 06:48:33 -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 15AE16B0071 for ; Thu, 10 Aug 2023 06:48:33 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E40891C8995 for ; Thu, 10 Aug 2023 10:48:32 +0000 (UTC) X-FDA: 81107871264.06.8BFC216 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf13.hostedemail.com (Postfix) with ESMTP id 2201B2001B for ; Thu, 10 Aug 2023 10:48:30 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691664511; 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; bh=Xxs5p4t1SDS5v4F3hr5MB+FRoGLt1jB0xXEcoGTBeqA=; b=kcvIhB62p9IKcdA/aDDXeiqBUBU/U3sc4ttvwnOVdZALEZC8GMgmZB8kU2o7miWRsFPOjR mxPucQJcvMrX+KXwoJpBGekxWMirKJ8B60ZmHFfV6IFqxcAydQ/ZDExAcdt+1Ocsk+G7ey VYEmOrV7ayJuwD6FUo+waF4WRO8Ad6I= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf13.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691664511; a=rsa-sha256; cv=none; b=kpoZo0zYkjoyKLp2tD/WiQYRjp6UThrcr/UkYnvglFT6BkCdDcrQnT6puLTSLNy/a7L1j6 lrom9WQHXmlMOTnJLlLVDZlcioNBV9SzsKCvjGIZA4T7sKbl7N9/M00Oe5GP7bcl5n1aBH RJuLJ51RoT7p3w5u3cuMODAkOFkB52M= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A39D4D75; Thu, 10 Aug 2023 03:49:12 -0700 (PDT) Received: from [10.1.27.169] (XHFQ2J9959.cambridge.arm.com [10.1.27.169]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 86E073F64C; Thu, 10 Aug 2023 03:48:28 -0700 (PDT) Message-ID: <155bd03e-b75c-4d2d-a89d-a12271ada71b@arm.com> Date: Thu, 10 Aug 2023 11:48:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH mm-unstable v1] mm: add a total mapcount for large folios Content-Language: en-GB To: David Hildenbrand , Peter Xu Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org, Andrew Morton , Jonathan Corbet , Mike Kravetz , Hugh Dickins , "Matthew Wilcox (Oracle)" , Yin Fengwei , Yang Shi , Zi Yan References: <20230809083256.699513-1-david@redhat.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 2201B2001B X-Stat-Signature: xokmjtnyz3n4agn86d3khi9gfycq1dqs X-HE-Tag: 1691664510-430971 X-HE-Meta: U2FsdGVkX1/AdvTNTplP5x5SLPCoyuDP7j/z4Ml0VXQfS4qg3PeevP8t/64odrFGSLg51LQvR4hcedlqgZuJg0tREVwTVM7yuDC1YWWxaWw2Dtj1jNMcBPwDT40xj3Zgl0wCQ7r3/KtuNhJ7MJY51XI1UOw813QB8R/jL+eGCtn3V2jgqssAXjk/HhKfLeznkrxMdotLeIYPze0Gp/u5tvrlpchmbRwiEPdSY2SNwEJMpFHaXxTND4zA2MQbbIUDItIzT1sQ8hoxILYdFnChy6dGJoQmpfJGrTra8T61/1jWObB7xBamqn9jYOeu0gEHAEgeYj7c0U7CjNWG55XdAZTMyhXunYDjW6t98qE6F1IzY9jJlUPMPPrveKM2zUnXn/0doK5GkL/X6LnU6oyYASa6u4HrWJFhTwq2mKvqVkKaeslvAWy8rWRe+RxpwFfXOXV7uDqOPp5Wm5/7oWudXKaUmkzctroPKFTQXm2ViOv9hW89CU3deJtRgjY7DzgF4bi+crQIsdr2hLPugQXFYFfDQiff0BXK8XY3h7gV3uq2Hw1233SGAPoZgA01rGK7oFeAykgn4ZN51ap8PYTuwz7ReZihUre2SW2dXdVvJOwfNPwd9hHdhXRdXfEKv56E13YpIwhKTtjmJ1QJs5OMY0Q1i+vU8a1BYmuhDW0O2GfJ8Qka8FnLEPFX+uV06jjinnuISK82I1z9if1NxtLGOmm+VgMah11fLR9vIY/zMfCTO9paXmWHC2KG89agZldk46j35F5NZBIrNLI/5H87RHQZMF9+iWEcRhrB0mhnMe6Ut/aDhuKbYoU7Z3AuUCFKRGZajHdSMO1IqDG1crtXPkcBjoDUe2SOIzhlGk4nTYGYcUmUyex5b9IZOJrJZ43ujc4ggUr/F0j6bl10EB2RdLkuoiXoW6d+SFjKn9AvEd/4S9bGDRvsa1KXIhhqkwerR2JASGobKlhNUA8GRq/ vQGVv9qf LXljpO+lMeogw1Xl70kJdymDjlWpqAbpiT4L7Gi88JkZ7wWer3X7T9lnhToKdWtKKNbyWGbYRCROlX8Dy+vQ+LIyNWP8UjkvJfj9wJ0KyhEgm1K9mFLdQ/o8pL+mlaYUrUr4toHNBVeFp+pcgzWy+8q3RaPpE5knqveIciqg/5vizgp25bDlLCBOV0pxU3wnPqBIZEuqLDGokIO1qzr/5YMxy7plCRQIxVsxbvL5UY/qKSAESclSCgfBDMzzUk1QKiG2HWB9Bdb6iFbY= 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: On 10/08/2023 09:59, David Hildenbrand wrote: > On 09.08.23 23:23, Peter Xu wrote: >> Hi, David, >> >> Some pure questions below.. > > Hi Peter, > > thanks for having a look! > > [...] > >>> With sub-PMD THP becoming more important and things looking promising >>> that we will soon get support for such anon THP, we want to avoid looping >>> over all pages of a folio just to calculate the total mapcount. Further, >>> we may soon want to use the total mapcount in other context more >>> frequently, so prepare for reading it efficiently and atomically. >> >> Any (perhaps existing) discussion on reduced loops vs added atomic >> field/ops? > > So far it's not been raised as a concern, so no existing discussion. > > For order-0 pages the behavior is unchanged. > > For PMD-mapped THP and hugetlb it's most certainly noise compared to the other > activities when (un)mapping these large pages. > > For PTE-mapped THP, it might be a bit bigger noise, although I doubt it is > really significant (judging from my experience on managing PageAnonExclusive > using set_bit/test_bit/clear_bit when (un)mapping anon pages). > > As folio_add_file_rmap_range() indicates, for PTE-mapped THPs we should be > batching where possible (and Ryan is working on some more rmap batching). Yes, I've just posted [1] which batches the rmap removal. That would allow you to convert the per-page atomic_dec() into a (usually) single per-large-folio atomic_sub(). [1] https://lore.kernel.org/linux-mm/20230810103332.3062143-1-ryan.roberts@arm.com/ > There, > managing the subpage mapcount dominates all other overhead significantly. > >> >> I had a feeling that there's some discussion behind the proposal of this >> patch, if that's the case it'll be great to attach the link in the commit >> log. > > There were (mostly offline) discussions on how to sort out some other issues > that PTE-mapped THP are facing, and how to eventually get rid of the subpage > mapcounts (once consumer being _nr_pages_mapped as spelled out in the patch > description). Having a proper total mapcount available was discussed as one > building block. > > I don't think I have anything of value to link that would make sense for the > patch as is, as this patch is mostly independent from all that. >