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 D5ECAC35274 for ; Thu, 21 Dec 2023 04:35:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74E4D8D0002; Wed, 20 Dec 2023 23:35:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D6D58D0001; Wed, 20 Dec 2023 23:35:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5778F8D0002; Wed, 20 Dec 2023 23:35:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 435BF8D0001 for ; Wed, 20 Dec 2023 23:35:53 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 07AF8120613 for ; Thu, 21 Dec 2023 04:35:53 +0000 (UTC) X-FDA: 81589562586.07.EF95F6D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id 50488100008 for ; Thu, 21 Dec 2023 04:35:51 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=J5SiicJF; dmarc=none; spf=none (imf14.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=1703133351; 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=tIcyVTUvWTVmkOSCh+ORFYZ85sHYJlwaK0XklBB5ZHE=; b=VA+fWfD/G1E6xQFcKzUJXaTzyXkMMIrTIk1k3ulZ2on61znvP0CbUdu1JxJWa2Cwuu8PZu XVezJjsBEq910lnZ7GgwGOHQdANBaW6NJjqtvaRt++2gFSvOJpUUylxOga9rAS068hKib6 0wELOSLHFP3GcebXZtzI+zzjva3G554= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=J5SiicJF; dmarc=none; spf=none (imf14.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=1703133351; a=rsa-sha256; cv=none; b=0K5UqGSdXmpZypngCbXZdG76SLDP9wSxKVCoSjMSsy1ZIQKUUW5gOvNkMTvRY+iP5nRrtq R//yHX+83GMQ4MnxRyGqQnAMKZ67k1NTh1DmsCA7uT5v+LUAfG+xz91B8qk4M/H4jhxhdd 01kdIT289OWU1vjC4gYeFdcZc43B0fw= 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=tIcyVTUvWTVmkOSCh+ORFYZ85sHYJlwaK0XklBB5ZHE=; b=J5SiicJFI/O/bVfWLC9VcRBwHF U9hmYBbfiJcPZjDG2ibyXMa6qthx6h+v1tv+yKoz8BSXG+O9i2PyPnRFoIoAiUpb40np6jruW3neX Rm245sI6RMSP2h/ABE/mi5SJBBt6i4yfpffDKbQEdS58o4KyKbEVy+opaWPCYmYidI9VioICu3Lw4 VvEFkmZnKdQxBtV7BhngNLutAN3EzV1fNkboU9hAr/SNOGQnFvRHXKOz5yrzEptmSR1KGrciuzwrt m5HXofIZkyJ4YlEq4VMO2VY9T4mol5Ol3ZAv5rujEEhLxQcwSKWT2YEtsz11RjkvjH3Jwyjnj3gGD FDueA0yw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGAmg-004f5Z-Dq; Thu, 21 Dec 2023 04:35:46 +0000 Date: Thu, 21 Dec 2023 04:35:46 +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 03/40] mm/rmap: introduce and use hugetlb_add_file_rmap() Message-ID: References: <20231220224504.646757-1-david@redhat.com> <20231220224504.646757-4-david@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20231220224504.646757-4-david@redhat.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 50488100008 X-Stat-Signature: g6uxzuwr5ia3mjb4br89ucr56p5kdnyb X-Rspam-User: X-HE-Tag: 1703133351-65107 X-HE-Meta: U2FsdGVkX1+ebcpPon8GPb0G1D4XjO+dblkoFAG/23Eu+qiyW+T50RTtly/ONj2VmGRVV5OHf3NftRJkw9tpXrDjPVzAmEa3lIKNqF8NUUaE6qdWZCnMynANk5Kpex/Z/ph6xEAKb3FCMf9k4kLHhiMltoFdhjXbO41pEYk0YQCIARzUVmVjopJ7ybxNciZN++BFZHGMNHvpAukyigVFKoZpu64N2PILH5+h9/dSNAvYYk5oqFSxds9v9K+0bgz3Wc+nHrJWmkRmuLX+JNRmrxYzC9vkdrZTWO6h0PPbmptBzSgM0CzZ5g0bXe6LgK1vc9x+82pYh3dr2skxyoYDhU4WSPFeOuR0fTkAETTCIQVfIKMRbeIS6XTEyGknysQjHbvwlWSDtcE0ewiA4aD5yp81ngMTDfCYanGGLKTkG7ZN9klH71A9NApwIR+vpPf0YcwX26ZbA4j1XCJmIrkCcJVdXOWeui449OUznaWyS7Q97eczuUhC5PJ4RDFAkUJrWNNI8rWAQZkmv1/XApo/DBU4ct1DjxZVp1IiI+8WGXZACpNHwBGddDE7swhlv5YKR2I6g7VBCPUdvjdjMV3ZfHeyb9uy2Tq0Xqz0xzFpA+JgF9RjTpM3FXMNrgGyvXYXW7PQnaymqZb5ADV2+atNkWVnqBRr6C05Np/yaWrZxlHIWBwO2cT43r8RThERUvVNQQs6LpisX4qDquMBA0KQSjhC/JD/diXMj7wm7KPS+05Gr7/hYu6B6Dg6J1Ic5Ly03hg6UqVs+htluxC/10LHTZlUkXTAQ0L3VhpeSMCQHh5A0QrhL1Qr5jC+GyWpioAlwegzBeZtlGwfKrnmT60uKKAEN/25FsnvxAbsCDyXeWRGxzFXdZRsak6KmHbg8J+Xg9W+meMJyvkh6eRUyXT20p9dRKXO6PmC12bFt9gxPt4vMmTcgJorE8Aukaj5BJaQQ2qSejlLJdhVdR3U2VM czsPX796 5Z2CN2KiUyvkx5Lq3iwyxf924+36ZyAd8+SBiSXzPDI8WDkVAe5WNM0GUpsQWEhjNhcyqkfkstE5Hl9i9vliU8LKfo3b2619LyY2TVZt05YOIU+AXFeQx4BUcli8SVc18v7cl1vKTiKaZhY3/AjwQiMX1ru4dqViWFPGp5FkUae5+E0ZbwY2UzlA+yEQrTXRt8vr6uiAZZKoJXn9EBpOp9odtoVSqZNsEKWufjXcni3Xqf9eUSYlddCCGUn6Q+/SzSoWtTEhwHQAWAxDial5dweDOlQYI6SUUwbb5JjhGyj0fdcJYPIgqWcAMIDAWeO4cjkgt83v4FCzBFct+E3bDbCe9u3i7ugWugE22 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:27PM +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. > > Right now we're using page_dup_file_rmap() in some cases where "ordinary" > rmap code would have used page_add_file_rmap(). So let's introduce and > use hugetlb_add_file_rmap() instead. We won't be adding a > "hugetlb_dup_file_rmap()" functon for the fork() case, as it would be > doing the same: "dup" is just an optimization for "add". > > What remains is a single page_dup_file_rmap() call in fork() code. > > Add sanity checks that we end up with the right folios in the right > functions. > > Reviewed-by: Yin Fengwei > Reviewed-by: Ryan Roberts > Signed-off-by: David Hildenbrand Reviewed-by: Matthew Wilcox (Oracle)