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 1850FC47258 for ; Fri, 26 Jan 2024 00:16:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F4068D0005; Thu, 25 Jan 2024 19:16:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A3BB8D0001; Thu, 25 Jan 2024 19:16:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 86BA98D0005; Thu, 25 Jan 2024 19:16:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 786A78D0001 for ; Thu, 25 Jan 2024 19:16:25 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1C816A2519 for ; Fri, 26 Jan 2024 00:16:25 +0000 (UTC) X-FDA: 81719545530.07.9DCCFF8 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf07.hostedemail.com (Postfix) with ESMTP id 9BBB34000B for ; Fri, 26 Jan 2024 00:16:22 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=muerDLlB; spf=pass (imf07.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706228182; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=9KDt625KEOD1gCDeqty7TVr6LIRuvy11myShKNH4CWo=; b=G9CPLO93n0ftDpZhV25k5VBfVZRDvPfdMyp5P/0zXSCsiA/43dqCDNAZ6ZoGt93ThtQz1y xtUcn3bO9UcC0cw5l6pW5wOYKPkh2CtZQtbhahiBaBUYU8u71+EaitHCEPScXMUL7WBRoc GmOo2uYNNHvqAQ8PIKoNFaYBAf8bPCQ= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=muerDLlB; spf=pass (imf07.hostedemail.com: domain of sj@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=sj@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706228182; a=rsa-sha256; cv=none; b=VG6+1rD7wQukTwjDEv1K9tNhgDfA4KLZvPB5UtW8odpWfmcA47Mjms9jkrbikM0SYX4NJf +s40KR2OmZT0q9utFWrPgHZ/HnHF8jpTTj4UKwwRcJ/5X2axJi6KMEsyFT9MuA4klODUDt 7By7H3V0he9gqmYjo7Jju9VOt9SerYE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7F6D062387; Fri, 26 Jan 2024 00:16:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C73F8C433C7; Fri, 26 Jan 2024 00:16:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1706228181; bh=BQE4uFxJ4n9IV+zkasuNGMpbnIwMWAWBWZi5wAv6jIY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=muerDLlBPXD3ZmBXJtA5oy+muHSMpsBRCJFpJivO4lp8iAZGliKRmEuKQtvRK/VyK FaLX7gsFWGiuybvSqlB0miGOzlGL21eXEq8oDwIpnjsnvXFOqFzseqydTkjtllRi2u e7uT+oWRGBwJIOsY2GvQ5yOV/KFNh8I7JOLaLbzJfDUJVVnQAuJmvZDuG0hBVLqq46 ih+o5gVKpVlocwa+viF99du3JA1WZeXLpvNwrTE12XF8cynpf42OIwWWowD6aiKiuL Rdl4IpwrERxrc0CHxYHdZHIx0NVLpI8SyldJAtNOs8YgpFaL6mikbICOAgG7n4h1fx uMHlJ94K0IKzA== From: SeongJae Park To: David Rientjes Cc: Matthew Wilcox , John Hubbard , Zi Yan , Bharata B Rao , Dave Jiang , "Aneesh Kumar K.V" , "Huang, Ying" , Alistair Popple , Christoph Lameter , Andrew Morton , Linus Torvalds , Dave Hansen , Mel Gorman , Jon Grimm , Gregory Price , Brian Morris , Wei Xu , Johannes Weiner , SeongJae Park , linux-mm@kvack.org Subject: Re: [RFC] Memory tiering kernel alignment Date: Thu, 25 Jan 2024 16:16:18 -0800 Message-Id: <20240126001618.13281-1-sj@kernel.org> X-Mailer: git-send-email 2.39.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 9BBB34000B X-Rspam-User: X-Stat-Signature: y4xgrdmt55qfaxiuw88pps58xufwiu8y X-Rspamd-Server: rspam01 X-HE-Tag: 1706228182-772675 X-HE-Meta: U2FsdGVkX19vp3gGkF3zp/A+MEhPeCaPFJ5X+eKYpG5wmLQ8+tE8fKpSqNz9awxqDycdRq9vERh6Hl4QR/JrjneryOgSVp5387OancBtk2n9Qy3teuFqYTThF9zY/aUEQpa6yxW3fKIMtcKQoo+ybkxp8+wDPQd8CLxFFb/VMTuqA9IRsPdGUwjqZ7mBJnKKW7JrGACyS6/RjHv9syQGTAbEYgj7gRnojN0gYvQcEyHyBjYux/yd9ZBPbqusQJUbYqfJp8B02zsBi/+2Insy8iKg3kAGF9+2mQk0lYb/qEACluZ7GJBN+K+BvSQ//qnnkm/P2prSX25UVK4W1FIB0DQcGWFrWZkHQroi6EnVZaB4HjwL0NF7fSTQUVIBdnpzHMszlHVnlDk9fy1RQ5FOq/GM0QWMDaOBpR5ZHVEgEUYXPor6YaFOnd3wuWAc1p/fekzmjKOXwuOEgkYQsHLFKtg6u5SLYEWmsWia9IdLH0V1bQmGJPrvEmJmz37NDnjdRsKFHAO0Ub8GXTT45VVF1x6u0Kl5BjvqiSMWQTDeT2vcUpqmEpcxxCsKGhEj/+PnnaQZUpGHCxA6KrlS2W2DB7gKAXH+eXga/lnLlHWVVJ/VTE2gN7Kq5fEfAZ61PcGR1XeLZDsr4sSXqOedlnuS+VUD7lWb4EJTYq27MVPU3rbGD6LyVcHd9j7LWTnBEdDzgaiuPYmcZmM8A1nFkZptTZqJELEn6fSOlT0WyTdPnK23MdCiFIw/eFtK3ZDNrRMZvbtFX1OMxJXNDzNRSo6sXypLRyn9Q1MdEd96iWEeOeqnIlMmXUdDADAL+ub0orjAdcFnIROXRuS4BceE03pfIXbuYTTKy+EitNBpRAPpKiAeck4uLhwBzk1QrpgpzIE9kRvZk7zx4TZcaZycxOGnlV4Vhh5H6HWKHvPI0YDVrbmBwRjzycFMQO4q7M8TtTSs+H3NBFJabJtCKP0SNKO izDGzDhf XJPGv24FrK7/wrEdrzeXXeOl1dDuOBuC0lCyW 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 Thu, 25 Jan 2024 13:37:02 -0800 (PST) David Rientjes wrote: > > On Thu, 25 Jan 2024, Matthew Wilcox wrote: > > > On Thu, Jan 25, 2024 at 12:04:37PM -0800, David Rientjes wrote: > > > On Thu, 25 Jan 2024, Matthew Wilcox wrote: > > > > On Thu, Jan 25, 2024 at 10:26:19AM -0800, David Rientjes wrote: [...] > This is **exactly** the type of discussion we're looking to have :) > > There are some things that I've chatted informally with folks about that > I'd like to bring to the forum: > > - Decoupling CPU migration from memory migration for NUMA Balancing (or > perhaps deprecating CPU migration entirely) > > - Allowing NUMA Balancing to do migration as part of a kthread > asynchronous to the NUMA hint fault, in kernel context > > - Abstraction for future hardware devices that can provide an expanded > view into page hotness that can be leveraged in different areas of the > kernel, including as a backend for NUMA Balanacing to replace NUMA > hint faults > > - Per-container support for configuring balancing and memory migration > > - Opting certain types of memory into NUMA Balancing (like tmpfs) while > leaving other types alone > > - Utilizing hardware accelerated memory migration as a replacement for > the traditional migrate_pages() path when available > > I could go code all of this up and spend an enormous amount of time doing > so only to get NAKed by somebody because I'm ripping out their critical > use case that I just didn't know about :) There's also the question of > whether DAMON should be the source of truth for this or it should be > decoupled. I wouldn't dare to say DAMON should be the source of truth, but I hope DAMON to be somewhat useful. DAMON is designed to be able to be easily extended[1] for various access monitoring / memory management primitives including hardware features. DAMOS of today provides a feature called filter[2], which allows applying specific operations to specific pages depending on their non-access-pattern information including type (anon vs file-backed) and which memcg it belongs to. Hence I think DAMON might be able to be used for a few of above cases. [1] https://docs.kernel.org/mm/damon/design.html#configurable-operations-set [2] https://docs.kernel.org/mm/damon/design.html#filters Thanks, SJ [...]