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 E62FFC4167B for ; Tue, 28 Nov 2023 16:08:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C2276B0118; Tue, 28 Nov 2023 11:08:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 648876B0120; Tue, 28 Nov 2023 11:08:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4C2F96B0126; Tue, 28 Nov 2023 11:08:43 -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 37A2D6B0118 for ; Tue, 28 Nov 2023 11:08:43 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id D6B7CC02CA for ; Tue, 28 Nov 2023 16:08:42 +0000 (UTC) X-FDA: 81507846084.11.E80F345 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf07.hostedemail.com (Postfix) with ESMTP id F332340011 for ; Tue, 28 Nov 2023 16:08:32 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DwsFPT7x; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1701187713; 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=soyiTtP+gPlQ7bbuHvFbNVbbE3R/GLF0+Udhto1bAz0=; b=6NEqLikiYjXbbHm7g28XkZEA5b3sC5bCIXPplcPfBQJWGqD/dyoGoHBLJJgVzC6HdjxX4Y BD/FkZCo9WkqZVtVsGL9XOJl3b2volKvm6gWDSJw6vIdyIGsSnNZsKiI4fvwoXfoQ8OugJ ewOcGe6vQRg2jOE+bSmaRDCQKNKZEuc= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=DwsFPT7x; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf07.hostedemail.com: domain of peterx@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=peterx@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1701187713; a=rsa-sha256; cv=none; b=BqepHBeE2uJKli5MNffuTpSIqrCiHdi8QfFOeNgXqTqojKmdeqVlHECl8N8/uU/os7AVE2 kswiRcKQ0hwWOCy6uJhvd6/AjeQZZhVowJhXF8Xf/l7YSPLLbpUGtOJ56BZvsJ/MmaDpr6 OcpYIFPcHthxPOfDoChaKd02OLuBLls= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1701187710; 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: in-reply-to:in-reply-to:references:references; bh=soyiTtP+gPlQ7bbuHvFbNVbbE3R/GLF0+Udhto1bAz0=; b=DwsFPT7xieMxQJYBDJoXs64E6lKsNjIh9+MllyElQCLirH7RT2z5q9mVuYquAdFSakoIhU 1RYX78CwHvb5SCvCmqAMGOS2JJvznfOdKg5ySOWpaWywWiFnNjeYIUt4T7BOHIZjDOZ7dv CE2PqlbENkVg1FEx6HInqnp15kC7duQ= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-637-N34ujrIfMECsRcczfYKQQg-1; Tue, 28 Nov 2023 11:08:29 -0500 X-MC-Unique: N34ujrIfMECsRcczfYKQQg-1 Received: by mail-qt1-f197.google.com with SMTP id d75a77b69052e-4239f7f5304so9748661cf.0 for ; Tue, 28 Nov 2023 08:08:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701187708; x=1701792508; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=soyiTtP+gPlQ7bbuHvFbNVbbE3R/GLF0+Udhto1bAz0=; b=eYAHyCusmYwc+pkLQ7LmZwMwkeoQ7D7Zapf3iZAU0ofUAJTMM6JBjLdaCWx94vh+a3 GvRqCCDrPieBoAXz9L+J0TSFCBqBSDknf13DCmNRIxTT6uT//ZLMkbGmgYwLPC+evCoS ASnCizgt+QaClXQBoheL+CIWzxf1SCZarNkJKEGUVParTQtzYN+SJR3vloyV1kWn0kBX KUKmhZLGP+gzxwHX+F+kNZE9K70vZrnKV/hT476HmmsdmxhY95iZZd1gzLnS264dPdjr /O9dcEUNXSubebWvdmVjCnWEbOoz2e3oSln+QNXTubdJBEQhI7+5MfZiaUxNyREFkRX8 HfcA== X-Gm-Message-State: AOJu0YxzZayYgMnBzqH53Y/04+NBo2hzG6yeC++Y0brW6kv9z3by0Pt7 dps3sygq+6VGwdEHG2aPShdUzobMBSEBL7Wc77HhgXChpn50DKyVwF1R9cstMdhEdLMrarCeoMp ZhsMthl2mmN4= X-Received: by 2002:a05:6214:3018:b0:67a:8e0:bf28 with SMTP id ke24-20020a056214301800b0067a08e0bf28mr16757311qvb.3.1701187708093; Tue, 28 Nov 2023 08:08:28 -0800 (PST) X-Google-Smtp-Source: AGHT+IEWn9jMOhnDF2ZZIcrQo8ekWA9To5I3Zb1UyODKnTrxbo30MQjzPmKMNb+UeJSmsZZSB4OYMw== X-Received: by 2002:a05:6214:3018:b0:67a:8e0:bf28 with SMTP id ke24-20020a056214301800b0067a08e0bf28mr16757283qvb.3.1701187707742; Tue, 28 Nov 2023 08:08:27 -0800 (PST) Received: from x1n (cpe688f2e2cb7c3-cm688f2e2cb7c0.cpe.net.cable.rogers.com. [99.254.121.117]) by smtp.gmail.com with ESMTPSA id a24-20020a0ca998000000b00677a12f11bcsm5234822qvb.24.2023.11.28.08.08.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Nov 2023 08:08:27 -0800 (PST) Date: Tue, 28 Nov 2023 11:08:25 -0500 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Mike Kravetz , Muchun Song Subject: Re: [PATCH v1 2/5] mm/rmap: introduce and use hugetlb_remove_rmap() Message-ID: References: <20231128145205.215026-1-david@redhat.com> <20231128145205.215026-3-david@redhat.com> MIME-Version: 1.0 In-Reply-To: <20231128145205.215026-3-david@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: F332340011 X-Stat-Signature: bqdmjdk3sekotfqutx5316z9bgi4rdfx X-Rspam-User: X-HE-Tag: 1701187712-608924 X-HE-Meta: U2FsdGVkX18w7mB5VgevsxNnXoDwO3owbyUnF4DiPzhUDn5nHdhYreD1Y1yBdFL9o/SaAqOE0TooR+gSezCq4/MnjMgHcxPxgeOzLWogCKTG+ua31jr/k2JehEzG+C37KWJWrhlnqsqf6f2+x2294u+XLc3CMQYgZ/WbsswcsNtRBV6pJDvPh3P//jl5tRuvcf36rxmeNkMhEsqcYrUfhVlIhQXsqr5GKK/aRdJmPVVnA+NO1jCrbSIiPdCpo36qMAlyL48ChzS06uZhqG/WbHbxdo3luYWjit7YMfJ1P4FCqacX5LSFPdIHDE/AftK0VDJr5l6kUTCHZQpUeQJN6CPvKts327aJrUFaAYe6FJVsTtQm27Ty78qHXYYw12vKJUgzjUcoZMb5ZlyRaTI0937YO75lu1MVSXiPCRZPepQODmGMtQfmd6SJ1ijFJssPBkGnNcPheS1gTSYQTibxOOjXtrpugR94nniVFXvds4KX8UhAGPBBz2ErKemm+gTeBviU8aqcwk8WVPBG4KLs2MPE49pWFDuv5TL15kz57MEYvcJ8HXbU7QXP8cuPAXF4MUEFYH24PxiUJ+sVHauqwJ0aetupYSgGe+mMOtzOGjY4MeAsoDyecL8GQ4xbQElDfeH4JRQ345hqMzDHvTOY8YizOxWc4B3Q2H26XVoWEO+QY8tlHwl4Gvi5ol28B2gs7F64EciqXqMJgKTuf49Y0K6rWlEON8B2zk2u/fd2DEZnPhOtD3uTvFJVSFXm3btzjSRbvLXxHHMErIiuX9v4MJq2e0iylHXQYPQ78nLPdaQUuSYAAPld5NrWmwDajNU1PROo6Qfm8LIkBNPRc/MYsh3H6TMdiQ0yljedF3ZMQiI2e7LJkzWbX3cyPbVNiO6dXLLHy6WdBU4CPcen3/Nj2hrv3afLCeWEWZ2hOur0cvwEb6tVD/wSW/PHPC4sfCuYnwpEGVapW0dfXCIdyIX wDtLLzwN 9riK9fKixswVKPxLrZpNrtAp4R+Sk+WgDorkGh7km6xzxUOv6uCBms1mxKfYsswawpYf0Tq0mb7UrPXEyuPSR85QfMAYY3ALGr2Jf39jeK0hms6a0lZsdvQO3e7Ax9MiosW+GN29nHm1++8UhbTYqfjm9TZXA06l7zNdOmggo7XtD4JdRaJwQcZ33uG27K0/+jHPn7pcDNY2kuMbeZbAzLo7NaUmUrVS6cTNFurwajR+psnzfz/DonIG2FdH0VY5pseghjSwg7MPup7QAjU7jlibHhcm+MUy0eTQdm9upyR5JELhNhHkQu6vvoLtM6ngP+IND8jSGR9EVcWLPlWE1ukSR1FcCdlwgBKroLkaRUfgrsFkxZ3lADCl/HtTrJ8fSP5P1GHzJLj0vC9BIxu8ZmwiY8L+yN5RfJ7M6t6nd/AZY8J5iUTov7WJw7w== 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 Tue, Nov 28, 2023 at 03:52:02PM +0100, David Hildenbrand wrote: > hugetlb rmap handling differs quite a lot from "ordinary" rmap code. We > don't want this hugetlb special-casing in the rmap functions, as > we're special casing the callers already. Let's simply use a separate > function for hugetlb. We were special casing some, not all.. And IIUC the suggestion from the community is we reduce that "special casing", instead of adding more? To be explicit below.. > > Let's introduce and use hugetlb_remove_rmap() and remove the hugetlb > code from page_remove_rmap(). This effectively removes one check on the > small-folio path as well. > > While this is a cleanup, this will also make it easier to change rmap > handling for partially-mappable folios. > > Note: all possible candidates that need care are page_remove_rmap() that > pass compound=true. > > Signed-off-by: David Hildenbrand > --- > include/linux/rmap.h | 5 +++++ > mm/hugetlb.c | 4 ++-- > mm/rmap.c | 17 ++++++++--------- > 3 files changed, 15 insertions(+), 11 deletions(-) > > diff --git a/include/linux/rmap.h b/include/linux/rmap.h > index 4c5bfeb05463..e8d1dc1d5361 100644 > --- a/include/linux/rmap.h > +++ b/include/linux/rmap.h > @@ -208,6 +208,11 @@ void hugetlb_add_anon_rmap(struct folio *, struct vm_area_struct *, > void hugetlb_add_new_anon_rmap(struct folio *, struct vm_area_struct *, > unsigned long address); > > +static inline void hugetlb_remove_rmap(struct folio *folio) > +{ > + atomic_dec(&folio->_entire_mapcount); > +} > + > static inline void __page_dup_rmap(struct page *page, bool compound) > { > if (compound) { > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 4cfa0679661e..d17bb53b19ff 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -5669,7 +5669,7 @@ void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct *vma, > make_pte_marker(PTE_MARKER_UFFD_WP), > sz); > hugetlb_count_sub(pages_per_huge_page(h), mm); > - page_remove_rmap(page, vma, true); > + hugetlb_remove_rmap(page_folio(page)); > > spin_unlock(ptl); > tlb_remove_page_size(tlb, page, huge_page_size(h)); > @@ -5980,7 +5980,7 @@ static vm_fault_t hugetlb_wp(struct mm_struct *mm, struct vm_area_struct *vma, > > /* Break COW or unshare */ > huge_ptep_clear_flush(vma, haddr, ptep); > - page_remove_rmap(&old_folio->page, vma, true); > + hugetlb_remove_rmap(old_folio); > hugetlb_add_new_anon_rmap(new_folio, vma, haddr); > if (huge_pte_uffd_wp(pte)) > newpte = huge_pte_mkuffd_wp(newpte); > diff --git a/mm/rmap.c b/mm/rmap.c > index 112467c30b2c..5037581b79ec 100644 > --- a/mm/rmap.c > +++ b/mm/rmap.c > @@ -1440,13 +1440,6 @@ void page_remove_rmap(struct page *page, struct vm_area_struct *vma, > > VM_BUG_ON_PAGE(compound && !PageHead(page), page); > > - /* Hugetlb pages are not counted in NR_*MAPPED */ > - if (unlikely(folio_test_hugetlb(folio))) { > - /* hugetlb pages are always mapped with pmds */ > - atomic_dec(&folio->_entire_mapcount); > - return; > - } Fundamentally in the ideal world when hugetlb can be merged into generic mm, I'd imagine that as dropping here, meanwhile... > - > /* Is page being unmapped by PTE? Is this its last map to be removed? */ > if (likely(!compound)) { > last = atomic_add_negative(-1, &page->_mapcount); > @@ -1804,7 +1797,10 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, > dec_mm_counter(mm, mm_counter_file(&folio->page)); > } > discard: > - page_remove_rmap(subpage, vma, folio_test_hugetlb(folio)); > + if (unlikely(folio_test_hugetlb(folio))) > + hugetlb_remove_rmap(folio); > + else > + page_remove_rmap(subpage, vma, false); ... rather than moving hugetlb_* handlings even upper the stack, we should hopefully be able to keep this one as a generic api. I worry this patch is adding more hugetlb-specific paths even onto higher call stacks so it's harder to generalize, going the other way round to what we wanted per previous discussions. Said that, indeed I read mostly nothing yet with the recent rmap patches, so I may miss some important goal here. > if (vma->vm_flags & VM_LOCKED) > mlock_drain_local(); > folio_put(folio); > @@ -2157,7 +2153,10 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, > */ > } > > - page_remove_rmap(subpage, vma, folio_test_hugetlb(folio)); > + if (unlikely(folio_test_hugetlb(folio))) > + hugetlb_remove_rmap(folio); > + else > + page_remove_rmap(subpage, vma, false); > if (vma->vm_flags & VM_LOCKED) > mlock_drain_local(); > folio_put(folio); > -- > 2.41.0 > > Thanks, -- Peter Xu