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 02577C5472D for ; Wed, 28 Aug 2024 06:17:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 603946B00AF; Wed, 28 Aug 2024 02:17:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58CA16B00B0; Wed, 28 Aug 2024 02:17:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42CF56B00B1; Wed, 28 Aug 2024 02:17:42 -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 236EA6B00AF for ; Wed, 28 Aug 2024 02:17:42 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id BF3D9161C7E for ; Wed, 28 Aug 2024 06:17:41 +0000 (UTC) X-FDA: 82500647922.13.401C75F Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf04.hostedemail.com (Postfix) with ESMTP id 65AA040008 for ; Wed, 28 Aug 2024 06:17:38 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TnvNRs8e; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724825839; 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=ObRuyq7FNJIiMeYkwRvwqbuxmxvXvw13eLW91K5Ip5Q=; b=YrEEC3VM5jvaTiQkATovCxripMMAJue1vIuYN+k+2V4TsNMEzHEeJY4v4PmEnCd9GrFEcU 59bVm2Bqo3BuE18dQmmH/i6l6mWXUED60lVYh/0Hto8D/MoFI/6vFxKz0vnwxAZL51vwR7 V7ygfCENLa8LeHy4E5zMwWr9KcE6mbg= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=TnvNRs8e; spf=none (imf04.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 198.175.65.10) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724825839; a=rsa-sha256; cv=none; b=MWXWmE2qh+kX0A1zVUhn7gFm6lPyDhn7GEl0QjCdteV4G0HNp+1MDHz6C4QulanZsprK3r zWVb/fMq+EPlFq/OzdBnR3d9Pd02WDMj0ZwDiYDvi4bc8y4fdY8WEMVLjlr/rIbpvzNRf/ WnGOPnkPkcxVkvi1OSQk1ba5O04W6UA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1724825859; x=1756361859; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=N7D0w95cp/r1m6Xu8l24R+M33YOTjjUOZNZE60X/7Dg=; b=TnvNRs8eQ3RWLL53tEYUMYyN5sZxyc7pEUms2a1u9sNclUdib4SksGE6 8Bl8J+oqXcvM1Of9N+1/Mpx5oomRZJhflm2BvkeWrfrUgZaSHVCPpeaQ8 tTveVnhxZ2LcfSg2tKI1qBDrLXe5h9v+OKAQsjgtUJ4ogzlOzUp8DFsWF VPqqon5FfdWocJallD1A/RVD+kGw6uzcsZusaq3QTExyReCOA+FphU75D dEBPJE7aa5MLn/8BQgT3kEsI9gBhHXMpty7ZDZuu4G/uVEAVIUyk4tRWS t0DlBL3p6wuJ8krckXDgSOj/8c6KV4VHC++/l8Ww/YcrwkixN7PyfJjM4 w==; X-CSE-ConnectionGUID: 4v4me9ZtTfSz9xHFir6c1A== X-CSE-MsgGUID: eMbAj1MWTJ2ICATVmwMJiA== X-IronPort-AV: E=McAfee;i="6700,10204,11177"; a="40809977" X-IronPort-AV: E=Sophos;i="6.10,181,1719903600"; d="scan'208";a="40809977" Received: from orviesa002.jf.intel.com ([10.64.159.142]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 27 Aug 2024 23:17:37 -0700 X-CSE-ConnectionGUID: 1mKfn2JpSu2KtJ8a7fNUCA== X-CSE-MsgGUID: HuWHYxoBTY6lcwh4GJ9twg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.10,181,1719903600"; d="scan'208";a="93827911" Received: from black.fi.intel.com ([10.237.72.28]) by orviesa002.jf.intel.com with ESMTP; 27 Aug 2024 23:17:32 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id D8699142; Wed, 28 Aug 2024 09:17:30 +0300 (EEST) Date: Wed, 28 Aug 2024 09:17:30 +0300 From: "Kirill A . Shutemov" To: Rik van Riel Cc: Johannes Weiner , Usama Arif , Nico Pache , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, Andrew Morton , David Hildenbrand , Matthew Wilcox , Barry Song , Ryan Roberts , Baolin Wang , Lance Yang , Peter Xu , Rafael Aquini , Andrea Arcangeli , Jonathan Corbet , Zi Yan Subject: Re: [RFC 0/2] mm: introduce THP deferred setting Message-ID: References: <20240729222727.64319-1-npache@redhat.com> <72320F9D-9B6A-4ABA-9B18-E59B8382A262@nvidia.com> <61411216-d196-42de-aa64-12bd28aef44f@gmail.com> <698ea52e-db99-4d21-9984-ad07038d4068@gmail.com> <20240827110959.GA438928@cmpxchg.org> <9cf237df1a7bb21bba1a464787938eba8f372658.camel@surriel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9cf237df1a7bb21bba1a464787938eba8f372658.camel@surriel.com> X-Rspam-User: X-Stat-Signature: g7e3qxxxdu1w4tuw3kgh7qd6ogr4ymxi X-Rspamd-Queue-Id: 65AA040008 X-Rspamd-Server: rspam11 X-HE-Tag: 1724825858-825104 X-HE-Meta: U2FsdGVkX18GvFORX2ewPzpccx7Kxvito0uvxQYj0PAYk/UoL7+MMGwYVm8mQdpUjhUwI2ToSj+sJoXEovpB8/bK1CP9wE0AiuDiLIwu7TamAYsW5DRkqWOnWXnZ9mEFDH8WKPy7dCCtWVEbKYmb0QxfzG2gdoG7VNdPx939wjTdcuqA/H0mSnL3OsguCP7ebrOnvPYQxzhCLzQcHxfbfm2hl3nWCUwbbP3p4M+abbvW9Pz9kpdWQpJAtLtJXFwUNl2cmAYwVeRoRTz7V/JeSpX8HHTfEkTfjJOvbPF+1Op3MJ5vzZAzJ+HdTkz1jABXbQS8yifqDm3SXfJNXvYc/6U1FeuvNTgm1s+A5AikqtYT8ri97GT2JY04mGaqXGFfpSFbdqx/7pW58T6O29UNGUNym6BFvo2TbeWGMZHwCjIKYmHGQCFivrS0M2kk5/MyztVvgmfLMBEKRRPBfbW+d5EKJUDbAeB/TlaDx5cFPaib0lf3vHjCSiu/2aiFdBJOnPqJL9K3+FaSvCKAjPotVmM8LuCUs1egvU0+LTQqCpniIStM0w8A7jkctB1Sal2vn+sciBXVvbRL3SYxczLf6H0zrRk8VXCX2oawkSENi++6ApqljX4xuLajxD3vVg8TBBTO0C/iqdosbWPULutAPMNAyRRw5SUeGDOPU/dn4tNhY7KvevbczVSDXDB6CqvUe+wiljwovrzTiMs2fXCxxGEfhS6cpGsURvL/e+Wim8Na4MoMhf1y0cZvThjOxa08GJycwIr/jzUZBM4L6S94z1GxsZfA5dbIxIoA5GwzaiVwqJt4EbNKMqneQxxEsedc05LL0GQZgTb9w6Y9dTM3ktqWn7cMx/jFDpMSrx7f8usTW7PIjxSA9/B0TMLekvqu0UO7MmHmWCDycMImCxQIGasO7FwH8B0ScrJQxkpZB142BNOtrob9pW318PKDnqH7XYSU2IKv6Dzw3xhmDEa LbSWS9m/ yjZXw9okpnf5f+QGOL0LjjtMd/OfIeLGaBP2CktczkiYv2lz+/gRUgIB5ApGG3ERZGvI+n0Hj6+BAbk7AE3Uvsw+I9cK2RYE/SrfiyzamteGzl4+LL7TKjkkJccviooAeI9I35XYIdOzvWkH8kggkOYxgqZNcTGU8A0GRtPIH9atHUDWYGagkT5Jj1Q== 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 Tue, Aug 27, 2024 at 09:18:58PM -0400, Rik van Riel wrote: > On Tue, 2024-08-27 at 13:09 +0200, Johannes Weiner wrote: > > > > I agree with this. The defer mode is an improvement over the upstream > > status quo, no doubt. However, both defer mode and the shrinker solve > > the issue of memory waste under pressure, while the shrinker permits > > more desirable behavior when memory is abundant. > > > > So my take is that the shrinker is the way to go, and I don't see a > > bonafide usecase for defer mode that the shrinker couldn't cover. > > > > > I would like to take one step back, and think about what some real > world workloads might want as a tunable for THP. > > Workload owners are going to have a real problem trying to figure > out what the best value of max_ptes_none should be for their > workloads. > > However, giving workload owners the ability to say "this workload > should not waste more than 1GB of memory on zero pages inside THPs", > or 500MB, or 4GB or whatever, would then allow the kernel to > automatically adjust the max_ptes_none threshold. The problem is that we don't have and cannot have the info on zero pages inside THPs readily available. It requires memory scanning which is prohibitively expensive if we want the info to be somewhat up-to-date. We don't have enough input from HW on the access pattern. It would be nice to decouple A/D bit (or maybe just A) from page table structure and get higher resolution on the access pattern for THPs. I tried to talk to HW folk, but it went nowhere. Maybe if there would be a customer demand... Just saying... -- Kiryl Shutsemau / Kirill A. Shutemov