From patchwork Tue Jun 13 16:09:48 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ryan Roberts X-Patchwork-Id: 13279028 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 410AEEB64D8 for ; Tue, 13 Jun 2023 16:10:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=m+NOmfLOWvPeUJ2qhqqISHgdsKMenfT8gQjrgVAiD7o=; b=WPXM+ClxNRl/1R pzbHMI0f2ALSFNUfgZa/J1+qeOyUIWN5TWwLQVd9UWvQmpieadhsIG0Fy1avP5oiCI+WJ854ReQRM XG7TELudBxaHEAfp6l/Ryv+FUTNwWOqgI3I0N/vp3Flclp4eLIhrxB8JS1esRy7weRQoXU9V4R6v8 /S0onEayaHbHei/XHwlzBy707gFnaVNHoVFQ1qkbhGdsEiipyVm8HkeNW0N6hpMhtXja3ZnYUUr+S SIXpHPkAti+j1fG+Uoa58POgZdvWq3fBAw6aqEWU/SG+1Bw1viMqnEeYXTMQY8jZVEQx4TEP0MuZl aSeKg6hyEnEmr/I5mZtw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q96b1-008YDi-0q; Tue, 13 Jun 2023 16:10:15 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1q96as-008Y8L-15 for linux-arm-kernel@lists.infradead.org; Tue, 13 Jun 2023 16:10:10 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id F24661FB; Tue, 13 Jun 2023 09:10:46 -0700 (PDT) Received: from e125769.cambridge.arm.com (e125769.cambridge.arm.com [10.1.196.26]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BAA7D3F5A1; Tue, 13 Jun 2023 09:10:00 -0700 (PDT) From: Ryan Roberts To: Jonathan Corbet , Andrew Morton , "Matthew Wilcox (Oracle)" , Yu Zhao Cc: Ryan Roberts , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH v1 0/2] Report on physically contiguous memory in smaps Date: Tue, 13 Jun 2023 17:09:48 +0100 Message-Id: <20230613160950.3554675-1-ryan.roberts@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230613_091006_444058_DE9EB6B4 X-CRM114-Status: GOOD ( 16.20 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi All, I thought I would try my luck with this pair of patches... This series adds new entries to /proc/pid/smaps[_rollup] to report on physically contiguous runs of memory. The first patch reports on the sizes of the runs by binning into power-of-2 blocks and reporting how much memory is in which bin. The second patch reports on how much of the memory is contpte-mapped in the page table (this is a hint that arm64 supports to tell the HW that a range of ptes map physically contiguous memory). With filesystems now supporting large folios in the page cache, this provides a useful way to see what sizes are actually getting mapped. And with the prospect of large folios for anonymous memory and contpte mapping for conformant large folios on the horizon, this reporting will become useful to aid application performance optimization. Perhaps I should really be submitting these patches as part of my large anon folios and contpte sets (which I plan to post soon), but given this touches the user ABI, I thought it was sensible to post it early and separately to get feedback. It would specifically be good to get feedback on: - The exact set of new fields depend on the system that its being run on. Does this cause problem for compat? (specifically the bins are determined based on PAGE_SIZE and PMD_SIZE). - The ContPTEMapped field is effectively arm64-specific. What is the preferred way to handle arch-specific values if not here? The patches are based on mm-unstable (dd69ce3382a2). Some minor conflicts will need to be resolved if rebasing to Linus's tree. I have a branch at [1]. I've tested on Ampere Altra (arm64) only. [1] https://gitlab.arm.com/linux-arm/linux-rr/-/tree/features/granule_perf/folio_smap-lkml_v1 Thanks, Ryan Ryan Roberts (2): mm: /proc/pid/smaps: Report large folio mappings mm: /proc/pid/smaps: Report contpte mappings Documentation/filesystems/proc.rst | 31 +++++++ fs/proc/task_mmu.c | 134 ++++++++++++++++++++++++++++- 2 files changed, 161 insertions(+), 4 deletions(-) --- 2.25.1