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 EFA79C433EF for ; Tue, 23 Nov 2021 21:31:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FB836B0072; Tue, 23 Nov 2021 16:30:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AAE96B0074; Tue, 23 Nov 2021 16:30:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 372466B0075; Tue, 23 Nov 2021 16:30:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0201.hostedemail.com [216.40.44.201]) by kanga.kvack.org (Postfix) with ESMTP id 2A5B76B0072 for ; Tue, 23 Nov 2021 16:30:56 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id F3B708A9D9 for ; Tue, 23 Nov 2021 21:30:45 +0000 (UTC) X-FDA: 78841489650.28.662E464 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 88E741046334 for ; Tue, 23 Nov 2021 21:30:42 +0000 (UTC) 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=iO3HnBWsJ/NLxaA52RztLHbEXc3qbezCQwSQjG1Zx/M=; b=qsGcdrrxcb86GaRuvr7c46R+V0 Hc5/2hIoSps0xhhYrfmKeFMhNzRqW7Ge8YfRF5IukxnfV44DLP0fHjKE+CeOV3q2OvGJ2vnpAUKYY kHH4rL8+6ecd9BzzhNnmu5pr3P9lOsXeu/1JufgGtIVGK+AYtu82BYq5I1s4kXB6LRmwSN14SGChX InHnHV4Nm/vBl6Yca6+UGx1xM8K2hmYlCRopgX9PKQah0rZbDg5WlmVue67SJEu9qNaDlAZQHw9Xg uJmRkr8vb7Qtu3szPc48E3Gbz0KFwcdLQSj/LrxgwA5ZuOj6etsXlwkJEMhZ7yETeZSMN7XTkChOY tY+cwS5g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mpdN0-00GUOj-7Q; Tue, 23 Nov 2021 21:30:30 +0000 Date: Tue, 23 Nov 2021 21:30:30 +0000 From: Matthew Wilcox To: Mina Almasry Cc: Jonathan Corbet , David Hildenbrand , "Paul E . McKenney" , Yu Zhao , Andrew Morton , Peter Xu , Ivan Teterevkov , Florian Schmidt , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-doc@vger.kernel.org Subject: Re: [PATCH v7] mm: Add PM_THP_MAPPED to /proc/pid/pagemap Message-ID: References: <20211123000102.4052105-1-almasrymina@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 88E741046334 X-Stat-Signature: u6ighy3ksngoy3nyw13771dsmdmdytyj Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=qsGcdrrx; dmarc=none; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-HE-Tag: 1637703042-556740 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 Tue, Nov 23, 2021 at 01:10:37PM -0800, Mina Almasry wrote: > On Tue, Nov 23, 2021 at 12:51 PM Matthew Wilcox wrote: > > > > On Mon, Nov 22, 2021 at 04:01:02PM -0800, Mina Almasry wrote: > > > Add PM_THP_MAPPED MAPPING to allow userspace to detect whether a given virt > > > address is currently mapped by a transparent huge page or not. Example > > > use case is a process requesting THPs from the kernel (via a huge tmpfs > > > mount for example), for a performance critical region of memory. The > > > userspace may want to query whether the kernel is actually backing this > > > memory by hugepages or not. > > > > So you want this bit to be clear if the memory is backed by a hugetlb > > page? > > > > Yes I believe so. I do not see value in telling the userspace that the > virt address is backed by a hugetlb page, since if the memory is > mapped by MAP_HUGETLB or is backed by a hugetlb file then the memory > is backed by hugetlb pages and there is no vagueness from the kernel > here. > > Additionally hugetlb interfaces are more size based rather than PMD or > not. arm64 for example supports 64K, 2MB, 32MB and 1G 'huge' pages and > it's an implementation detail that those sizes are mapped CONTIG PTE, > PMD, CONITG PMD, and PUD respectively, and the specific mapping > mechanism is typically not exposed to the userspace and might not be > stable. Assuming pagemap_hugetlb_range() == PMD_MAPPED would not > technically be correct. What I've been trying to communicate over the N reviews of this patch series is that *the same thing is about to happen to THPs*. Only more so. THPs are going to be of arbitrary power-of-two size, not necessarily sizes supported by the hardware. That means that we need to be extremely precise about what we mean by "is this a THP?" Do we just mean "This is a compound page?" Do we mean "this is mapped by a PMD?" Or do we mean something else? And I feel like I haven't been able to get that information out of you.