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 67B83C47258 for ; Sun, 28 Jan 2024 20:15:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 854BE6B0075; Sun, 28 Jan 2024 15:15:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7E7426B007B; Sun, 28 Jan 2024 15:15:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67DF86B007D; Sun, 28 Jan 2024 15:15:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 5213F6B0075 for ; Sun, 28 Jan 2024 15:15:43 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 011C5A072F for ; Sun, 28 Jan 2024 20:15:42 +0000 (UTC) X-FDA: 81729825366.04.067897E Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf02.hostedemail.com (Postfix) with ESMTP id 38DFF8001A for ; Sun, 28 Jan 2024 20:15:41 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o2xE3wgS; spf=pass (imf02.hostedemail.com: domain of rientjes@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706472941; 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=PhoB7D2VwRLK6vEH0+E3uRH2X9QcBSGJ7QEr0wKkRwg=; b=Gce2Nvab1nI3cXSOBitsHvd/VGln25X9B2GZDEF9KlgaveElgq0QBBIpkV1tK2McMuwKM/ g+UEe4zLlxJ7bWgFqe+cCVNTqInbF75iWuVa6DsuOyf4ObATUby/1m3ixZHL6nS5hwhEBJ OwBXnU6my/yw5a5B7Dt930bJHIiQVVE= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=o2xE3wgS; spf=pass (imf02.hostedemail.com: domain of rientjes@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=rientjes@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706472941; a=rsa-sha256; cv=none; b=7GZIfYfwDkI0yHZzc3YKLFpVf7BkZoQ7olzw7HMZEA1E8pSE7R6HamlQEI8pUYjnfN7Onq gkg6uPoFlrfA+7FtFE59ynObDsbP9Jsugd8QW9+9BFpF2Arg0IG8ix1haa5uR68nAFGvkk RC8ITputUXmBbWIUQumRH8mNnDj39gY= Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1d5ce88b51cso188145ad.0 for ; Sun, 28 Jan 2024 12:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1706472940; x=1707077740; darn=kvack.org; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=PhoB7D2VwRLK6vEH0+E3uRH2X9QcBSGJ7QEr0wKkRwg=; b=o2xE3wgSykTsbb7Lj/lYr4NcWnAcOZYK3NG/d1QCKBx3QeU/ymPHKEey3KCPBNwHwt FQezLZqqVtHotynOS/u2mNH8/Nwy1V7032l6Z67I+4Jv/4xj9KPq7w8GIrT0pFI8IIis 4VOJiG6qeCs/tT90DvdS9eJ0LUydEJazLkb7XuCxIs6s3Q56bnP0w/Y1NvRq0GpxEVK/ GFlpumAcSKIQ32AM568jzEiqeGDAzqlYFlwDnE+HDMnHkCawZciuNVvBNWtIDYufgLTn f1qFaPG0SzJiGUCWvVXLjMb6BNs7P4q8Y6utAY8rTVLJWrZHeNu0KPhOSOSd4RhKL0/H fRfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706472940; x=1707077740; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=PhoB7D2VwRLK6vEH0+E3uRH2X9QcBSGJ7QEr0wKkRwg=; b=M0U9CcmNqamKpDE27bRv/U0wErKGYWbqUB5hxYJlaFrmFG85rT8ISYudTg4F/2lK8e tdMVf2uv2q1yBTvcjA0/Mn1MOK1Nu+o1S0P6o/SVNEPunoKvxuCk/flth2/Kpz8bbev4 RVY6M6g1qfqqcLhY6zv5SV5oj1PVrUlS8aaE7BATQvW+hvZUo9ViO9rIuNHPPnVZc+0p XIaI5AM15gfkOeopelM4lq+v3tDpfMiMwKRqj0jWhorVsPX8j5RUQXH62qZKkUM35R3e 287Yf52MGiw0ZO3kUq0+qx0jd5ZtnobXXhZwBXaGyf2rEItwpPqGY9B0O/sElhsIVPTT euVQ== X-Gm-Message-State: AOJu0Yw/9JwkcEzc/QJFZHYUqH0kMbxlAnF6orXNM+pw/UH6ksEIml2i vxCAyccfNnz1cEMEqRLZwAFGMQY9Gz03Jalx/7fzogUHyBi/UiqKZlXPJtvDAg== X-Google-Smtp-Source: AGHT+IESR5vRZjqawxvxef3FwX6xjhGR6uX2LAopgeMIfk9D+dCTCDT6A3wYbhniHVIMNRuk6QtZSw== X-Received: by 2002:a17:902:bb01:b0:1d4:ca8c:aa6d with SMTP id im1-20020a170902bb0100b001d4ca8caa6dmr484794plb.0.1706472939766; Sun, 28 Jan 2024 12:15:39 -0800 (PST) Received: from [2620:0:1008:15:5f4:aa23:10dc:18a8] ([2620:0:1008:15:5f4:aa23:10dc:18a8]) by smtp.gmail.com with ESMTPSA id m10-20020a170902f20a00b001d8aa88f59esm3223651plc.110.2024.01.28.12.15.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 28 Jan 2024 12:15:39 -0800 (PST) Date: Sun, 28 Jan 2024 12:15:38 -0800 (PST) From: David Rientjes To: Matthew Wilcox cc: 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 In-Reply-To: Message-ID: References: <75f21150-1e12-4f4b-e578-e170e4fea18b@google.com> <2b29dd3d-bb2c-6a8c-94d2-d5c2e035516a@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 38DFF8001A X-Rspam-User: X-Stat-Signature: cmeancafbii5o1qobz44ij7m1m8w5ae5 X-Rspamd-Server: rspam01 X-HE-Tag: 1706472940-803131 X-HE-Meta: U2FsdGVkX19e3LP/1FjM7kzqnkXgAZe1k7LF0HlzoghYUkUHRSxlsv/m9PJb2Yje71dxjyf+g7B7ta3rBET50OU/RCr78939O/cPmtfCFtfnePtOrFxlOh4j6vMJ/jpAhkZCX36ew5QDdi5N6xz/zqqWvNjZV8/x7a1ZmN5DwCx7y6cQAK6Aqdty4R9idW+kV1C/N263/lGOVhaVLYg1CxPqykeXd0Is4MGzZT6eFhbNByzOecw0PmVyg9K2hmk9r8Q4u+V++QlTvyh8dvBg8zb1xaaRQwYLr7RnKmXASDfvNoVd4dToGd0154ZMIEHOL++w12yh7SMTs/YTsbtE07jjoc4ZE2ZlsSAQw+kP5yajF+BBOD3TnTNivUCagMb6hvXg1WEuGBZAKVAZk0w3lR9E4ZHC6cAqr2Zf14squy4QxGNAaSO9hMBGXf4MjGavMMY/74vUemGSnFMC+loLVU69I+lYTHdmAIzLXVqfeIobt3KzuXJ8H/UVnwe8oBVLAMtGg/s8CEflAvSCbjVBfSQjwtAAHYFP6vg0ABWznt5IKxN6hbPEbfiY4dQ6CIxj90dv5+j1TLnM0k9OCMTi95Xh1mLEJeDv6C40CM394ToE8nujwqkLuLz6wzy7EzKWI/q67nSGoPWZ6gEr3JT6R4bsRvwZtPTZrKiuDKUJyTXxOLUHsTIcexY7kAFkWlD774+PbT2GvYy8kfJFH2iDnFHMqkRV0pAg4lIc+zI1EJmI8YKE2MY9i7t7L+JE6oKzuDZB5pakjTYnwUXMET5GpG/9GixkWPY6OV+RZITQgUQUlAfvsRaxXKuqtFvAduTi+N26u2FxRXdtfwD0gUhdtd5U0eEvmp+6dT8gpfgVpzCIKwXb+SPoZphcT4gbqr8bLWXuBl2hBr2UsPX2axF3AK46ctlZRtOSvSwZEyvXzjbaoJspERsBoe0VBM1+mYmCmgi2eX9KJPVaYL5kEbo QhtIVfnh HbRoQyM7FaiXJaLZ9ilgk19rhqIsGk5m7IYSFlqluR92Tv7CH6DJpRCfYhIu9xUZvKbEDdz46/z1v61ui8WsIoi+ZYprYaF9u9E/thnf1mB37L3P0CdTeHE+mSmaFsKsynqJ5X9MebLM+xAOwCzm4JlP5yP/UNl6B/Jnfzp+E2WNTwDApxmPjVHSz+YNx8NPS12lxtUKy5i23ZCoTCRTJFJyx5PPT7DugHX37C1+nbldor3luptkRbuFvjSt9LMS9bvfpVtv5KmXvYYkToQHsYD0vNbL6MGXdYpj9BYEXNaUiWjyJp/Ae2GYNdt496LOFMNJibRkdIRNDMdOqLubwhkb0SksIBtW5hzbcwrlVz7lbj5af+ReNehWGRnsDaLE0XBZ94roSnLqgGutw5AFn7mKQzATOqR+AvES5MvXhoOaZGHiDjp2XJ9MwJKv/lc4vvcbFb5cGRrr6O9p8xPViYRTHpS54Z2Pj0Cn4 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, 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 > It would be absolutely stunning if all of the above is non controversial :) I would imagine that there are some (perhaps strong) opinions polarized between "ok, this makes sense" and "ok, this seems crazy" for each one of these. Or, at least, "prove to me that this makes sense." We can definitely wait for this work group to be formed and then come back to the mailing list, but any early feedback on these would be much appreciated especially if the opinions are polarized toward the at least some of these being on the crazy side.