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 CF557C433F5 for ; Wed, 5 Jan 2022 04:40:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BD3AB6B0071; Tue, 4 Jan 2022 23:40:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B82496B0073; Tue, 4 Jan 2022 23:40:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A71EE6B0074; Tue, 4 Jan 2022 23:40:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0065.hostedemail.com [216.40.44.65]) by kanga.kvack.org (Postfix) with ESMTP id 991886B0071 for ; Tue, 4 Jan 2022 23:40:03 -0500 (EST) Received: from smtpin18.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3B80C181CAC7C for ; Wed, 5 Jan 2022 04:40:03 +0000 (UTC) X-FDA: 78994981086.18.8BE9733 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 5560720007 for ; Wed, 5 Jan 2022 04:40:02 +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=i6uYjQM6a+w//FCMGzjfe0KtBTgocro5T9Tkc6vxins=; b=NeTlfINWf+IFbE4Az2T9/P0eVE aA5vY9D1w5ArKSl3EJx0PSAVrzmxBcLW47YG54b8dGACGKjZGvCu79NSwszQomhyOR2LVisqgGrm4 LBIrQfjljvI+LUysEmND531G7CTV9G49mDkbD3TXufevdcKM1co5Dl6HV2WHbjHhoTGvDA2gGFPFm 3r5wbQSrjFEXTjDsQHaiaJnDipB7NhxTf9Q6UHZLZb+leRtyPON4/yGzNkbI7oF1tyqF3V98EfxDi ZUgr8zYAW8M4DenCKbzNG2PdE+NFgQzp4e+kmYCaHV9iJOnv6i8BfTUXYHh1GiTD4pg0D8yBGr7Nt Piw6dRoA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1n4y5P-00EGSs-US; Wed, 05 Jan 2022 04:39:43 +0000 Date: Wed, 5 Jan 2022 04:39:43 +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-Stat-Signature: tycmufumw3xrrr8f14cmjxxwfc4kcynb X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 5560720007 Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NeTlfINW; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none X-HE-Tag: 1641357602-793602 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, Jan 04, 2022 at 03:04:31PM -0800, Mina Almasry wrote: > On Mon, Dec 13, 2021 at 4:22 PM Mina Almasry wrote: > > > > On Sat, Nov 27, 2021 at 8:10 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. > > > > > > But what is userspace going to _do_ differently if the kernel hasn't > > > backed the memory with huge pages? > > > > Sorry for the late reply here. > > > > My plan is to expose this information as metrics right now and: > > 1. Understand the kind of hugepage backing we're actually getting if any. > > 2. If there are drops in hugepage backing we can investigate the > > cause, whether it's due to normal memory fragmentation or some > > bug/issue. > > 3. Schedule machines for reboots to defragment the memory if the > > hugepage backing is too low. > > 4. Possibly motivate future work to improve hugepage backing if our > > numbers are too low. > > Friendly ping on this. It has been reviewed by a few folks and after > Matthew had questions about the use case which I've answered in the > email above. Matthew, are you opposed to this patch? I'm not convinced you need more than the existing stats (THP_FAULT_FALLBACK) for the information you claim to want.