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 5DC81C433EF for ; Thu, 7 Jul 2022 14:46:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D2F966B0072; Thu, 7 Jul 2022 10:46:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id CDF476B0073; Thu, 7 Jul 2022 10:46:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BCD78900002; Thu, 7 Jul 2022 10:46:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id ACD4E6B0072 for ; Thu, 7 Jul 2022 10:46:57 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2E18933E68 for ; Thu, 7 Jul 2022 14:46:57 +0000 (UTC) X-FDA: 79660580874.24.C90CA71 Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by imf22.hostedemail.com (Postfix) with ESMTP id E098CC0056 for ; Thu, 7 Jul 2022 14:46:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1657205216; x=1688741216; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=KZoOhYr8rZQDf+CrGeMco6Jgl7zOhXbo9W38e2RlFZY=; b=dPwk7Owo2nPQWIYkttnkWzoHsSiuEvdB0CmqAQLsDwhjOzBvQ08FZYPO /IBkrbHBUBNag26dzf+KD68rmwA4dqK6xhTY2XwtFElNcyNKr2xzL+uFf WA6iq2XaxB8PO9VHYo7Lyqr2cD7FjCtkZu2liJNIbCiPubQp8lwNQjQoj MrT1lxI5+81TtcRjAQLu5X/ZbAS37Sgbg93k5tzMX7QJTsiGSwn9QMq5Q AbNvKCYCeuVaKc3NqO5k4bJw5VfqBmtgSpOrA3KRbmomzFSYl40CwzZAH l4iOwrjpvm2P4hQQwUT3ahjwahzPpEI1RQpwp87pJKYeTo4UrsUBA7Iyq Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10400"; a="263824100" X-IronPort-AV: E=Sophos;i="5.92,253,1650956400"; d="scan'208";a="263824100" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2022 07:46:52 -0700 X-IronPort-AV: E=Sophos;i="5.92,253,1650956400"; d="scan'208";a="568544278" Received: from nmajidi-mobl.amr.corp.intel.com (HELO [10.251.17.238]) ([10.251.17.238]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 07 Jul 2022 07:46:51 -0700 Message-ID: <8821beda-4d60-4d01-b5c8-1629a19c7f0d@intel.com> Date: Thu, 7 Jul 2022 07:44:39 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH 0/3] Add PUD and kernel PTE level pagetable account Content-Language: en-US To: Baolin Wang , akpm@linux-foundation.org Cc: rppt@linux.ibm.com, willy@infradead.org, will@kernel.org, aneesh.kumar@linux.ibm.com, npiggin@gmail.com, peterz@infradead.org, catalin.marinas@arm.com, chenhuacai@kernel.org, kernel@xen0n.name, tsbogend@alpha.franken.de, dave.hansen@linux.intel.com, luto@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, arnd@arndb.de, guoren@kernel.org, monstr@monstr.eu, jonas@southpole.se, stefan.kristiansson@saunalahti.fi, shorne@gmail.com, x86@kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, loongarch@lists.linux.dev, linux-mips@vger.kernel.org, linux-csky@vger.kernel.org, openrisc@lists.librecores.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1657205216; a=rsa-sha256; cv=none; b=HmRUbNWdDjt8fSBGCSbcVfoZo+ivj/IxQTjB4YBlQvFvcw5/FFuwme5YOXq3cfvjaiL0ik fh1ibPIToPL+sBoJzbmK0Q2a+wNmpNrzlTvn10jeeYi9amqM49bV/0l2CT7GJSVogedEwc qjeiCwNwWjTdCPM9iP30VvDGvu6YczQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dPwk7Owo; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1657205216; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7AMPoftm8+aeW7zN6E5QNEDGuvhW3oZlLgvz+PXoHLA=; b=8Sm3CU8pNjBXXkrDtStiQirt8LAjRkuRy154+Nk3En5c/WF8bx/Y5dZh1LNG0VDM/CHIDW aESFSAeE1JaWKsx96V9GdXjlFvULAEEDFEKlizQBPDt6MJw/PGVzoRGSsXqm1eOp3Go4Ew dfDMQSPsIDRPn9RCPCIh7yMrktG0lAk= X-Stat-Signature: s63fbca9no3ek47c789gq7gzh19k1r6p X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: E098CC0056 Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=dPwk7Owo; dmarc=pass (policy=none) header.from=intel.com; spf=none (imf22.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.136) smtp.mailfrom=dave.hansen@intel.com X-HE-Tag: 1657205215-931703 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 7/7/22 04:32, Baolin Wang wrote: > On 7/6/2022 11:48 PM, Dave Hansen wrote: >> On 7/6/22 01:59, Baolin Wang wrote: >>> Now we will miss to account the PUD level pagetable and kernel PTE level >>> pagetable, as well as missing to set the PG_table flags for these >>> pagetable >>> pages, which will get an inaccurate pagetable accounting, and miss >>> PageTable() validation in some cases. So this patch set introduces new >>> helpers to help to account PUD and kernel PTE pagetable pages. >> >> Could you explain the motivation for this series a bit more?  Is there a >> real-world problem that this fixes? > > Not fix real problem. The motivation is that making the pagetable > accounting more accurate, which helps us to analyse the consumption of > the pagetable pages in some cases, and maybe help to do some empty > pagetable reclaiming in future. This accounting isn't free. It costs storage (and also parts of cachelines) in each mm and CPU time to maintain it, plus maintainer eyeballs to maintain. PUD pages are also fundamentally (on x86 at least) 0.0004% of the overhead of PTE and 0.2% of the overhead of PMD pages unless someone is using gigantic hugetlbfs mappings. Even with 1G gigantic pages, you would need a quarter of a million (well, 262144 or 512*512) mappings of one 1G page to consume 1G of memory on PUD pages. That just doesn't seem like something anyone is likely to actually do in practice. That makes the benefits of the PUD portion of this series rather unclear in the real world. As for the kernel page tables, I'm not really aware of them causing any problems. We have a pretty good idea how much space they consume from the DirectMap* entries in meminfo: DirectMap4k: 2262720 kB DirectMap2M: 40507392 kB DirectMap1G: 24117248 kB as well as our page table debugging infrastructure. I haven't found myself dying for more specific info on them. So, nothing in this series seems like a *BAD* idea, but I'm not sure in the end it solves more problems than it creates.