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 4AFE0C6FD1D for ; Wed, 15 Mar 2023 22:58:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6F01A6B0071; Wed, 15 Mar 2023 18:58:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 678D76B0072; Wed, 15 Mar 2023 18:58:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 519186B0075; Wed, 15 Mar 2023 18:58:49 -0400 (EDT) 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 3EBFD6B0071 for ; Wed, 15 Mar 2023 18:58:49 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 114A3140A2D for ; Wed, 15 Mar 2023 22:58:49 +0000 (UTC) X-FDA: 80572649178.05.C41B308 Received: from out30-73.freemail.mail.aliyun.com (out30-73.freemail.mail.aliyun.com [115.124.30.73]) by imf03.hostedemail.com (Postfix) with ESMTP id AA76820011 for ; Wed, 15 Mar 2023 22:58:46 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=aliyun.com header.s=s1024 header.b=Ift42UYM; spf=pass (imf03.hostedemail.com: domain of nh26223@aliyun.com designates 115.124.30.73 as permitted sender) smtp.mailfrom=nh26223@aliyun.com; dmarc=pass (policy=quarantine) header.from=aliyun.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678921127; a=rsa-sha256; cv=none; b=JyuROqZY0BU4LEipv6eCzEbZQqweIXt5cuHzUJuQH5MTgnlQF09YNb6SDH5qi84NLgoCtY nTBB+PoTSzq86B6Vy8j32aXk6AOq9c6DDMm4fvCX2xvMKTVzocmgyA/ZSiiocwvShYkUpo dvepvCXfK8yipZvDWc2n/me0Dv2Y5u8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=aliyun.com header.s=s1024 header.b=Ift42UYM; spf=pass (imf03.hostedemail.com: domain of nh26223@aliyun.com designates 115.124.30.73 as permitted sender) smtp.mailfrom=nh26223@aliyun.com; dmarc=pass (policy=quarantine) header.from=aliyun.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678921127; 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=MTmKa5JT2SfspbvYFYEoRFddv0o8rxotrqNIxps73zM=; b=zRg1mLuKZSKz3Jvqv/8aznLx+7xg3xAt6uGc8d3ok/KEv0wpE0IQOV8ke37fTXZK//+3zV jNsq/d02QjjFq/smf/9drmvSaKLofUa3a2va1rX6+tl4p9QQX7u538UbjDtO+ZJbwmrFAH mH2ZRZ4iGXzfROGg17WEdJWlK2AT9sA= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliyun.com; s=s1024; t=1678921123; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=MTmKa5JT2SfspbvYFYEoRFddv0o8rxotrqNIxps73zM=; b=Ift42UYMWQ4DXPy7aE4AX7iULlCVDoKPWlZs4qJGrQ+af0CY/bfunkCM94mq/VWKEN2yXikupL1DgsTfImNO9ZLVyUpGgo7AQJeMOgYhyFE+AIR5HXGaFiySXCw/1zrO1UC2JdSNBbtgNH+OZv2lz8W8iW0ZUfOzD+v5n+W2wpg= X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07357567|-1;CH=green;DM=|CONTINUE|false|;DS=CONTINUE|ham_alarm|0.0466106-0.000237194-0.953152;FP=0|0|0|0|0|-1|-1|-1;HT=ay29a033018046056;MF=nh26223@aliyun.com;NM=1;PH=DS;RN=6;RT=6;SR=0;TI=SMTPD_---0VdxUdJf_1678921113; Received: from 192.168.71.29(mailfrom:nh26223@aliyun.com fp:SMTPD_---0VdxUdJf_1678921113) by smtp.aliyun-inc.com; Thu, 16 Mar 2023 06:58:42 +0800 Message-ID: <25049671-a1ba-97ed-009d-b976a7cb6375@aliyun.com> Date: Thu, 16 Mar 2023 06:58:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v4 34/36] rmap: add folio_add_file_rmap_range() Content-Language: en-US To: Ryan Roberts , "Matthew Wilcox (Oracle)" , linux-arch@vger.kernel.org Cc: Yin Fengwei , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230315051444.3229621-1-willy@infradead.org> <20230315051444.3229621-35-willy@infradead.org> <387dc921-de2b-f244-985c-d1e6336d5909@arm.com> <01071d9c-483f-2d95-87a6-e1030acaf8dd@arm.com> From: Yin Fengwei In-Reply-To: <01071d9c-483f-2d95-87a6-e1030acaf8dd@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: AA76820011 X-Rspamd-Server: rspam01 X-Stat-Signature: thaqtkyd65ojpzg7653uhg1xme5gn6jo X-HE-Tag: 1678921126-861 X-HE-Meta: U2FsdGVkX1/m4TQJLrFcWXLzFBweG9bWSg+vuh5cy0KmeLKMcOvOzwcS9Ut0ZJWAn1Cay/9ZeGeSyCHwpAby1UDREthjwJuole7lzyggZ0GYUmr2qy3ygzEFNzwMjdX/16UYAsL9V8Z2rtLoVJyps1cZllz68k9m59UqfKMlOtgpchdeSyJjOLk4Rb4pAczNWtJo2RNOZZ1v8zZORg8QQjktA+3ewHM5c5j0GMCsfSt3Bimpg3uAaBJzAeESQr6gkS3OGUbKoK6d+1JsFqttEJuQm0OvmH90sAiQmFgNxIPvLEeifG0JiwejWnsN5mwJzgMi12JeFIBBfeJcGHW6aUtZETZx2EGOu4Gb7BBlEIgLqxG/MLZZHCixar8iWYkYPNqIJZI+jfqzLzkhxFNC09Dx5uZ1Ncb5pC8InQf/MrgQjB+wDNGN5KY7KCeQacOZkonk1ZbQJ3N4vzEbDujyZF8n4hww7vIlFwn2inSINxQkcDJysFl5oKLgQuvMFYhbVBJ69Dl6LGkPJ3/DyaQnSeuX2ecHngYufNOsCwqX1BuODlMaEpX2gDC0W0QTGdiA2Sse6DuV8JfqvjbGTQf/kfMG40ekk2zuedvQN0U/SFyTWRY66DGDXCX+emA6EAUsC213mBqCcXNn8r36r/EkQnwCLUdodvfJtc6DqPw0iDC++tOxUyHFyfKx0DeKn0oNT+Ur1fxVoiWMandI3KFwwEhUTQkkugXPbeoEj9phWtEs4r2xgPRlDGATitlNL8Iu2j+Vj2ajEBrJ6xmqd7qWGfRV3vOu/VCPYIQA+U5S96DT+cOOVMHtDtFbN3elvEyYByXTJucA58eaybuQDKyGravDgXKDUD51GgTsjAWh5WMQBvjQhNGDJiTRSbbJgtfrDrCcCtkkjyg/dAQgfIUXPQYgkJ/qEg9HvfMK5Ms1e8xpRPuP1pLvokPcuKH4W/EWW7EdQyiPoaid2y13LFl OIS5mRv2 rcCWoL6jYEHywJu11bj/vBsoZ6NhtA5LKu9RWDFJVxT3gEUvHms6Nf/+IEirrs5Tmvn/ibSfD6N3YoD59E/jv/lxq67XHG47oi2kGDmGSluyRtQeMr3kUkn5QPjgLq2u1HHcKA+hbjdfpLGUbG4um8p6YgibjOETeZQj6+gvPqxtvaZIDk6rXwK43Fe6iNZitjXoTGORD+rIzvVLeYgCTdn10UcVdCVDnb+6UuDRg8faMNSoCe+B7D2z4HuSQbF/fWoZAyekp+E1ewjCUKGX9Mz47FiBPitqYH+CVbEMNUc6tIk7NBPXoGO4oGRnr3aE+PJ6vF+d9BDgbE8KiI5oh8HhvwkDMhnz/zsyWQXbC0ARH4Y92skordixY5tFId1KPb+bJ9qyPobzpMO/DZv5wHsCne6cWHpLv6k8C 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 2023/3/16 0:08, Ryan Roberts wrote: > On 15/03/2023 13:34, Ryan Roberts wrote: >> On 15/03/2023 05:14, Matthew Wilcox (Oracle) wrote: >>> From: Yin Fengwei >>> >>> folio_add_file_rmap_range() allows to add pte mapping to a specific >>> range of file folio. Comparing to page_add_file_rmap(), it batched >>> updates __lruvec_stat for large folio. >>> >>> Signed-off-by: Yin Fengwei >>> Signed-off-by: Matthew Wilcox (Oracle) >>> --- >>> include/linux/rmap.h | 2 ++ >>> mm/rmap.c | 60 +++++++++++++++++++++++++++++++++----------- >>> 2 files changed, 48 insertions(+), 14 deletions(-) >>> >>> diff --git a/include/linux/rmap.h b/include/linux/rmap.h >>> index b87d01660412..a3825ce81102 100644 >>> --- a/include/linux/rmap.h >>> +++ b/include/linux/rmap.h >>> @@ -198,6 +198,8 @@ void folio_add_new_anon_rmap(struct folio *, struct vm_area_struct *, >>> unsigned long address); >>> void page_add_file_rmap(struct page *, struct vm_area_struct *, >>> bool compound); >>> +void folio_add_file_rmap_range(struct folio *, struct page *, unsigned int nr, >>> + struct vm_area_struct *, bool compound); >>> void page_remove_rmap(struct page *, struct vm_area_struct *, >>> bool compound); >>> >>> diff --git a/mm/rmap.c b/mm/rmap.c >>> index 4898e10c569a..a91906b28835 100644 >>> --- a/mm/rmap.c >>> +++ b/mm/rmap.c >>> @@ -1301,31 +1301,39 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma, >>> } >>> >>> /** >>> - * page_add_file_rmap - add pte mapping to a file page >>> - * @page: the page to add the mapping to >>> + * folio_add_file_rmap_range - add pte mapping to page range of a folio >>> + * @folio: The folio to add the mapping to >>> + * @page: The first page to add >>> + * @nr_pages: The number of pages which will be mapped >>> * @vma: the vm area in which the mapping is added >>> * @compound: charge the page as compound or small page >>> * >>> + * The page range of folio is defined by [first_page, first_page + nr_pages) >>> + * >>> * The caller needs to hold the pte lock. >>> */ >>> -void page_add_file_rmap(struct page *page, struct vm_area_struct *vma, >>> - bool compound) >>> +void folio_add_file_rmap_range(struct folio *folio, struct page *page, >>> + unsigned int nr_pages, struct vm_area_struct *vma, >>> + bool compound) >>> { >>> - struct folio *folio = page_folio(page); >>> atomic_t *mapped = &folio->_nr_pages_mapped; >>> - int nr = 0, nr_pmdmapped = 0; >>> - bool first; >>> + unsigned int nr_pmdmapped = 0, first; >>> + int nr = 0; >>> >>> - VM_BUG_ON_PAGE(compound && !PageTransHuge(page), page); >>> + VM_WARN_ON_FOLIO(compound && !folio_test_pmd_mappable(folio), folio); >>> >>> /* Is page being mapped by PTE? Is this its first map to be added? */ >>> if (likely(!compound)) { >>> - first = atomic_inc_and_test(&page->_mapcount); >>> - nr = first; >>> - if (first && folio_test_large(folio)) { >>> - nr = atomic_inc_return_relaxed(mapped); >>> - nr = (nr < COMPOUND_MAPPED); >>> - } >>> + do { >>> + first = atomic_inc_and_test(&page->_mapcount); >>> + if (first && folio_test_large(folio)) { >>> + first = atomic_inc_return_relaxed(mapped); >>> + first = (nr < COMPOUND_MAPPED); >> >> This still contains the typo that Yin Fengwei spotted in the previous version: >> https://lore.kernel.org/linux-mm/20230228213738.272178-1-willy@infradead.org/T/#m84673899e25bc31356093a1177941f2cc35e5da8 >> >> FYI, I'm seeing a perf regression of about 1% when compiling the kernel on >> Ampere Altra (arm64) with this whole series on top of v6.3-rc1 (In a VM using >> ext4 filesystem). Looks like instruction aborts are taking much longer and a >> selection of syscalls are a bit slower. Still hunting down the root cause. Will >> report once I have conclusive diagnosis. > > I'm sorry - I'm struggling to find the exact cause. But its spending over 2x the > amount of time in the instruction abort handling code once patches 32-36 are > included. Everything in the flame graph is just taking longer. Perhaps we are > getting more instruction aborts somehow? I have the flamegraphs if anyone wants > them - just shout and I'll email them separately. Sorry for using another email. I am on travel and can't access my company email now. Can you share the flamegraphs to me? I'd like to take a look. As I remember, I didn't see the kernel build regression w/o these patches on ext4/xfs. Thanks. Regards Yin, Fengwei > >> >> Thanks, >> Ryan >> >> >>> + } >>> + >>> + if (first) >>> + nr++; >>> + } while (page++, --nr_pages > 0); >>> } else if (folio_test_pmd_mappable(folio)) { >>> /* That test is redundant: it's for safety or to optimize out */ >>> >>> @@ -1354,6 +1362,30 @@ void page_add_file_rmap(struct page *page, struct vm_area_struct *vma, >>> mlock_vma_folio(folio, vma, compound); >>> } >>> >>> +/** >>> + * page_add_file_rmap - add pte mapping to a file page >>> + * @page: the page to add the mapping to >>> + * @vma: the vm area in which the mapping is added >>> + * @compound: charge the page as compound or small page >>> + * >>> + * The caller needs to hold the pte lock. >>> + */ >>> +void page_add_file_rmap(struct page *page, struct vm_area_struct *vma, >>> + bool compound) >>> +{ >>> + struct folio *folio = page_folio(page); >>> + unsigned int nr_pages; >>> + >>> + VM_WARN_ON_ONCE_PAGE(compound && !PageTransHuge(page), page); >>> + >>> + if (likely(!compound)) >>> + nr_pages = 1; >>> + else >>> + nr_pages = folio_nr_pages(folio); >>> + >>> + folio_add_file_rmap_range(folio, page, nr_pages, vma, compound); >>> +} >>> + >>> /** >>> * page_remove_rmap - take down pte mapping from a page >>> * @page: page to remove mapping from >> >