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 C9270ECAAD1 for ; Thu, 1 Sep 2022 06:37:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 309BE6B0072; Thu, 1 Sep 2022 02:37:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2B88A6B0073; Thu, 1 Sep 2022 02:37:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 181166B0074; Thu, 1 Sep 2022 02:37:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 094076B0072 for ; Thu, 1 Sep 2022 02:37:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id D88021A0396 for ; Thu, 1 Sep 2022 06:37:35 +0000 (UTC) X-FDA: 79862560470.28.C803547 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by imf06.hostedemail.com (Postfix) with ESMTP id 1748B180044 for ; Thu, 1 Sep 2022 06:37:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1662014254; x=1693550254; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=A2XTYHLdK54zP0UzYmCclABXXG/4WGRskOSTW8QpayU=; b=CuY+Suf9/byImCpUTGZD8tTCSiD8F9rbPH0dcBxCV+L9vlKBXiAyu8Ck Oh8ZOb/6qHcwe2XrwL6nGlC1OZ5OTfed+oCJ2Y98fWQfOTOc/HJGu6t2J GSqwH4honPgcp2zcbrfqI4yDsvz9vL3K06sGEY61TmBF3BWbwr70Npi4z ZySvUUQFagk5ZBG8oDbReGjOKtqln6AKwtLJ0WNuFCYmmRP1sVwZrzPVG +AbuFq4XKkcEPM1l0lO/6C33eNVACHsIE3tXC4MWp7iiYJMGtnilJEt3V rFVmPFdWWuzd0hdAFspyYFPTDEkhq0ZNAqXvfhFZGL0mdpX58eCJdE8gt A==; X-IronPort-AV: E=McAfee;i="6500,9779,10456"; a="296912886" X-IronPort-AV: E=Sophos;i="5.93,280,1654585200"; d="scan'208";a="296912886" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Aug 2022 23:37:26 -0700 X-IronPort-AV: E=Sophos;i="5.93,280,1654585200"; d="scan'208";a="589357218" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Aug 2022 23:37:23 -0700 From: "Huang, Ying" To: Wei Xu , Johannes Weiner , Aneesh Kumar K V , Jonathan Cameron , Yang Shi , Tim C Chen , Dave Hansen , Dan Williams Cc: Linux MM , Andrew Morton , Davidlohr Bueso , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Alistair Popple , jvgediya.oss@gmail.com, Bharata B Rao Subject: Re: [PATCH v2] mm/demotion: Expose memory tier details via sysfs References: <20220829060745.287468-1-aneesh.kumar@linux.ibm.com> <22cb7a8a-84fe-04c7-41ea-50eff8184dc1@linux.ibm.com> Date: Thu, 01 Sep 2022 14:37:20 +0800 In-Reply-To: (Wei Xu's message of "Tue, 30 Aug 2022 00:17:18 -0700") Message-ID: <8735db1ty7.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1662014255; a=rsa-sha256; cv=none; b=YNH7mj7JuoXc24W6yBCYNrSaxetyNFJFr7fWqh0iWrZ6gBVYwKiRlmXBTTWJwuX6vGT4JX lSc2lqmMubxYjP/1Rwy5L5pKaE5lGE4F/rF00SrlafTkOf4e1yWTdUXUz1XSYBpgR/iB1V SbcsiHe3PeMWiS67xQWNm5O9Y/ILxss= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=CuY+Suf9; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1662014255; 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=0a5eb1q+PookASF0wGDBV4nxp9F6ql9P/r0Kb+4UxrE=; b=VYnrKNQb10DdM/dVnF+uH4opzcwL7FOTeAy4++fhoGeq40QLFcpTI1gF5++u6BPVQVB849 Fg6lsnrRKDkbHYyiXIAWdJDPFW78D0Bo8iWuoVuxBqcvG/4RYbSkwznCy0v/KUgRjrM9GP iQ0ZgyWFu07pa9eI0u1EcRZEgfdxIJM= Authentication-Results: imf06.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=CuY+Suf9; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf06.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.65 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam12 X-Stat-Signature: stjmdxcn33kodwqok198zw515ekp9afw X-Rspamd-Queue-Id: 1748B180044 X-HE-Tag: 1662014253-813451 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: Wei Xu writes: > On Mon, Aug 29, 2022 at 11:46 PM Aneesh Kumar K V > wrote: >> >> On 8/30/22 12:01 PM, Wei Xu wrote: >> > On Sun, Aug 28, 2022 at 11:08 PM Aneesh Kumar K.V >> > wrote: [snip] >> >> >> >> + >> >> +What: /sys/devices/virtual/memory_tiering/memory_tierN/ >> >> + /sys/devices/virtual/memory_tiering/memory_tierN/abstract_distance >> >> + /sys/devices/virtual/memory_tiering/memory_tierN/nodes >> >> +Date: August 2022 >> >> +Contact: Linux memory management mailing list >> >> +Description: Directory with details of a specific memory tier >> >> + >> >> + This is the directory containing information about a particular >> >> + memory tier, memtierN, where N is derived based on abstract distance. >> >> + >> >> + A smaller value of N implies a higher (faster) memory tier in the >> >> + hierarchy. >> > >> > Given that abstract_distance is provided, it would be more flexible if >> > we don't commit to the interface where N in memtierN also indicates >> > the memory tier ordering. >> >> >> IIUC this is one of the request that Johannes had ie, to be able to understand the >> memory tier hierarchy based on memtier name. >> >> >> + >> >> + abstract_distance: The abstract distance range this specific memory >> >> + tier maps to. >> > >> > I still think the name of "abstract distance" is kind of confusing >> > because it is not clear what is the other object that this distance >> > value is relative to. Do we have to expose this value at this point >> > if N in memtierN can already indicate the memory tier ordering? >> > >> >> I do agree that abstract distance is confusing. But IIUC we agreed that it is much better >> than other names suggested and is closer to already understood "numa distance" term. >> >> https://lore.kernel.org/linux-mm/YuLF%2FGG8x5lQvg%2Ff@cmpxchg.org/ >> > > "NUMA distance" measures the distance between two NUMA nodes. Per my understanding, "NUMA distance" measures the distance between the CPUs of one NUMA node to the memory of another NUMA node. > I bring it up again because this name will become a user visible > kernel interface, which we will need to live with for a long time. > Even if we decide to keep the name, it would be better if we can > define between which two (abstract) points the abstract distance > reports. My opinion is that "abstract distance" reflects the distance (latency+bandwidth) between the CPUs of one NUMA socket to a type of memory in the same NUMA socket. Hi, Johannes, What do you think about this? You are the inventor of the "abstract distance". Can you elaborate its definition? Best Regards, Huang, Ying > Another option is to remove this interface for now until it becomes > necessary to report abstract distances to userspace. [snip]