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 C0F1BC35274 for ; Thu, 21 Dec 2023 04:40:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 073F38D0002; Wed, 20 Dec 2023 23:40:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 024048D0001; Wed, 20 Dec 2023 23:40:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E54C58D0002; Wed, 20 Dec 2023 23:40:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D63948D0001 for ; Wed, 20 Dec 2023 23:40:33 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B0598A19E3 for ; Thu, 21 Dec 2023 04:40:33 +0000 (UTC) X-FDA: 81589574346.25.98F592B Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf28.hostedemail.com (Postfix) with ESMTP id 1D857C0013 for ; Thu, 21 Dec 2023 04:40:31 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="gX/kDnjR"; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703133632; 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=2zC04biBcA1BX1DOBH2ATIvTR6mxcapHZpr9s+7+ipo=; b=w4qr3VTLZqiOT3D8zA70YVYzI1mkXKPvHEREVxHwHZd015oFbHS9MUtQQ1YaEj9YEwhR4I owDdtnEb35WQ9aron/3TPGoMgwpZwl+689TSzA7Ka+BEsID53nCsJuzMY30HIu6lPtF+hD Z5UYVUu2KJL4oXG4svV8HRH4fq0yB9g= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b="gX/kDnjR"; dmarc=none; spf=none (imf28.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703133632; a=rsa-sha256; cv=none; b=KHTzVF7kgaRHYc89oHMsIA08lJA9doWouqJEGtbCvJ32srGN0JsTf18vTnm8jJxDMo7bBF 8P3N+SFjtKt+rHGoLV64lFOzpEGqcubHgqp5XOl6+HVACLXjSGNVzJ1XSNTCpQpC2T3PRj 7JYDLv04MT9Bvr6od+nEuvzx/3yoCyk= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=2zC04biBcA1BX1DOBH2ATIvTR6mxcapHZpr9s+7+ipo=; b=gX/kDnjRM5qvuJs5UqsVh1DEtN 59jtdoe8/wx6hHnhYxenSkG/dlM4FPFkW8g8HlOfkiMDAez1J303b9KPPZFrna7XzovY1ZmxA0aaB E+T/9pBzZXV+fcXMK8foeekpP9JrqktBKFbhROlMJM/lyLd7sAIG76ZeVlPnyrCR5A+z2nLLFQpGN Idx3KrYx+CLABup+FV/6m4zupf+qrvqNYbSdVsDDwfb5Th+cAYnxkJsmONyqo418VBrZvhyCqg6TM 36OVmzIuQB4AkGl7GTBVSoWdQm2KORjrLm7VveF3sf+5U2zAvXVyhoE/wg7wcsHJKPCGOpbhrfmN8 eS3nt3JA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGAr9-004fI2-QE; Thu, 21 Dec 2023 04:40:23 +0000 Date: Thu, 21 Dec 2023 04:40:23 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Hugh Dickins , Ryan Roberts , Yin Fengwei , Mike Kravetz , Muchun Song , Peter Xu Subject: Re: [PATCH v2 04/40] mm/rmap: introduce and use hugetlb_try_dup_anon_rmap() Message-ID: References: <20231220224504.646757-1-david@redhat.com> <20231220224504.646757-5-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231220224504.646757-5-david@redhat.com> X-Rspamd-Queue-Id: 1D857C0013 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: gjqctk38o3ji7a9q56ytbixc1mri3c7p X-HE-Tag: 1703133631-475615 X-HE-Meta: U2FsdGVkX19WvHstcmsMzJn+nKI8tXp1Owoc72cB6hVhUpFz0qm148kmJmASSKeEbyG6FwcbVBHvXp7L/KjOBVq3VrL66VA3aLUzfH+pZB7ttS8wHQ4FWiDlLs0No5l6gOft4ZOFd1ltpXGILylnG7pWkTEp1jmdanRKBUjnaQuenIvT6u88dgnfglMEkVeLY5d6gUUIDGAE1VfzMP++BCJRCF3GBlIcYhMArNYIQdub3ct91+xl8ua11X+LEu3LMhjJmH8MUY50gc9c5y7tXTcXS+HvQAsl0/+Q2bo/hK1zpW0bNTMIhkjmkAWMpjNrx/VqhKI8BuZrEWzv7W0J+xNeiBmoaCKds965inPKZFNUFH6dHyPInyoTW/CpYcwwz68eIlHVxrK0kCsS03SfQuMZR6nvZaqn/0Tx9mjCJaXNtLTC9g38K480tEen/F8YuuSTs6jeifnxJLbASlE8bT6W8PCrmaXvoyMsCUuU1CKxKrH/xAikRHANoa+M7Lz8lXrVaFdyXOtNUGpzG5bJd7Mr9igJcPP29k9qhrcMcnhA73SY1bpPdNq97FyxeuSV02k76mAzGxxP3uEw8mtaMQspIDtPGiowKYqpf0i6uM8qshEzoGlZbgc2K1Oc1OafkaQ3Lq9Bhaehtap7abgHhzHckCe060EbZ79QFOh/ZQWtWjgsR7nX6GpcKCv1rgI8NV+uRRGENFBdZeZBKt1jl7GjCE9BYYZCZqgHjqvYXSPic3TIFHo5mChYB7tiQ5D9JJKsNueLdkGP2Ly9TRZZ45NVeP2+bsWJMKZnGV+zLe/9jAbZ+QJsaBC6zgUW9gZBvix67wIkOxdoZH4WwiQLxjpCGtw30vf0pZQaWToV1XKk8RrmqF81Mi5ESvZQosVZkI3QnvAgKC+GCZ2PyuJLX9lCvh1vsXkVlK6Mb/kRgJU9UzJcpf8WYKm0gD1hm1vLOqxE08SEQbAHvtxdm+r U6Q+NnlM yM9SjVSVFi35zaFQJf+52lcMmPSoZ4OxgGM+iAgvXbNFWVV9TbPRgkr2idx4g8RHkrzc4rH9PjQtbwRcJqUQWYBYKjPJt56xv1ghOgnUH1wHjCN+kEuRXdbmpGdkA+oEG63sJ5eAKEEimn8S8xbj8ulF7TvhP6XxVHioaZImGdHGn1nBb/Oi5vn8qaUCWedx/3kMoJySpzi56ZTKqNwxXkfpj0S3EWfaqHX3pRcz4CsCYb8A0jVOLAHjBlfZf+9Y4VkIsdwb7ls2AnaoMT+xZBbKQfoeJENttc0/oGSPaDljIpWWxGCqTAPamshgAgHdFvxw5GEO5QVFdkVRGSGUmQbV3ycA1Cg6mcCNu 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 Wed, Dec 20, 2023 at 11:44:28PM +0100, David Hildenbrand wrote: > hugetlb rmap handling differs quite a lot from "ordinary" rmap code. > For example, hugetlb currently only supports entire mappings, and treats > any mapping as mapped using a single "logical PTE". Let's move it out > of the way so we can overhaul our "ordinary" rmap. > implementation/interface. > > So let's introduce and use hugetlb_try_dup_anon_rmap() to make all > hugetlb handling use dedicated hugetlb_* rmap functions. > > Add sanity checks that we end up with the right folios in the right > functions. > > Note that is_device_private_page() does not apply to hugetlb. > > Reviewed-by: Yin Fengwei > Reviewed-by: Ryan Roberts > Signed-off-by: David Hildenbrand Reviewed-by: Matthew Wilcox (Oracle) > +static inline bool folio_needs_cow_for_dma(struct vm_area_struct *vma, > + struct folio *folio) I particularly like it that you introduced this. > +static inline int hugetlb_try_dup_anon_rmap(struct folio *folio, > + struct vm_area_struct *vma) > +{ > + VM_WARN_ON_FOLIO(!folio_test_hugetlb(folio), folio); > + VM_WARN_ON_FOLIO(!folio_test_anon(folio), folio); > + > + if (PageAnonExclusive(&folio->page)) { I wonder if we need a folio_test_hugetlb_anon_exclusive() to make this a little more ergonomic? > + if (unlikely(folio_needs_cow_for_dma(vma, folio))) > + return -EBUSY; > + ClearPageAnonExclusive(&folio->page); ... and set/clear variants.