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 60BBEC433EF for ; Mon, 2 May 2022 15:20:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 798536B0072; Mon, 2 May 2022 11:20:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 720C26B0073; Mon, 2 May 2022 11:20:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C0C46B0074; Mon, 2 May 2022 11:20:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.a.hostedemail.com [64.99.140.24]) by kanga.kvack.org (Postfix) with ESMTP id 491A36B0072 for ; Mon, 2 May 2022 11:20:31 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 109EF2079C for ; Mon, 2 May 2022 15:20:31 +0000 (UTC) X-FDA: 79421164662.02.9DEC1B9 Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by imf12.hostedemail.com (Postfix) with ESMTP id 70D6440070 for ; Mon, 2 May 2022 15:20:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1651504829; x=1683040829; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=3eV2vVXH7WHHzEX7UlnYBUTcCZN92RvrzzPd/WWwpzQ=; b=BZEINP/Aqx4O23FGRitfFOiyzcWE0xAffHAyU15bJ5g6UlQ50233XBKk m6ml/ro2Gc73+h5+fsUWW0ctUa4JkX+6FpXKxT0qxz+oIBckIS9W8lnzt klQDjxhNp/2caRxbeoaYCq9LLJc43sVtGowOi9qXAbgIkiy77PwbXieff V5GwysmHgwtAxFussEz/ecV/ZKXL4yZhwqop/HBbrnnWhR2KrCu/2Gu9y rBKOQgLwWEpCVZsN+/pUdd0q9Pp1fqJx1GvvZdluqGXEk4qnSezLuKZMh jrkhP0p5SdY5/sPdbwZc/laPIPb7+jdgQEOo43d6SV3Wq1ts/UvURBvMM g==; X-IronPort-AV: E=McAfee;i="6400,9594,10335"; a="264828022" X-IronPort-AV: E=Sophos;i="5.91,192,1647327600"; d="scan'208";a="264828022" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 08:20:28 -0700 X-IronPort-AV: E=Sophos;i="5.91,192,1647327600"; d="scan'208";a="663565365" Received: from gsteinke-mobl.amr.corp.intel.com (HELO [10.209.165.8]) ([10.209.165.8]) by fmsmga002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 May 2022 08:20:26 -0700 Message-ID: Date: Mon, 2 May 2022 08:20:45 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Subject: Re: RFC: Memory Tiering Kernel Interfaces Content-Language: en-US To: Wei Xu , Andrew Morton , Dave Hansen , Huang Ying , Dan Williams , Yang Shi , Linux MM , Greg Thelen , "Aneesh Kumar K.V" , Jagdish Gediya , Linux Kernel Mailing List , Alistair Popple , Davidlohr Bueso , Michal Hocko , Baolin Wang , Brice Goglin , Feng Tang , Jonathan.Cameron@huawei.com References: From: Dave Hansen In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 70D6440070 X-Stat-Signature: pbxbi4p783i1w37kywngremuz74efz1p X-Rspam-User: Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="BZEINP/A"; spf=none (imf12.hostedemail.com: domain of dave.hansen@intel.com has no SPF policy when checking 192.55.52.93) smtp.mailfrom=dave.hansen@intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1651504815-627435 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: > The current memory tiering interface needs to be improved to address > several important use cases: FWIW, I totally agree. We knew when that code went in that the default ordering was feeble. There were patches to export the demotion order and allow it to be modified from userspace, but they were jettisoned at some point. > Memory tiering hierarchy is rebuilt upon hot-add or hot-remove of a > memory node, but is NOT rebuilt upon hot-add or hot-remove of a CPU > node. Yeah, this would be a welcome improvement if we can get there. > * /sys/devices/system/node/memory_tiers > > Format: node list (one tier per line, in the tier order) > > When read, list memory nodes by tiers. Nit: this would seems to violate the one-value-per-file sysfs guideline. It can be fixed by making tiers actual objects, which would have some other nice benefits too.