Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp2504117imi; Sun, 24 Jul 2022 23:28:48 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tpFRlFmjAz5211fcICgYXLN2unOm1z4Y3URzm3K01rYjWnzenvTVw43l4UpPxqshKWyUmS X-Received: by 2002:a17:90b:4d05:b0:1e0:b53:f4a3 with SMTP id mw5-20020a17090b4d0500b001e00b53f4a3mr30496859pjb.3.1658730527998; Sun, 24 Jul 2022 23:28:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658730527; cv=none; d=google.com; s=arc-20160816; b=sQnNmHXLbeQfH8U8pN5znH3nsQGEtwXgVscsbWDYy/RP495YsHvY2sJosktE7bTVmP y0oJmV716gOLIznUWSCLmE7370PZiOl7X3Upup6LHoI67m8gPf2vpRfqgyXxmSadPbSe nkNlHay3B3EHApgdviq343SkVN0EfDPLT21v3Tgi/nVMBoiR5NPRDAW7u0pcuXFbv/fQ DMmJapw5D0XCmLCyfJghc8XS8VwR1A5AHqEnzONdlUMVJI86zO7yg+K4vJegnBdc2tOj +B7q9IdMyg8eMkHeMY57IWsOlSIUstUDLPnBjO9cG9t1RxnJiuVf5dV8yZR7kiiztuO9 t7KQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:message-id:in-reply-to :date:references:subject:cc:to:from:dkim-signature; bh=VJV4z8daCeJS5CiVQgXJ3h/rKSHaxrz8VU2t9VzJknc=; b=WfonqIRGhdcSVURwW6WeqCSH28aaxB/sy8lMxyZhrKCSYxwpFfqsTBPCmI6UdOre/p snyD3kuA3KmQmOOBfx6WeEiuU1pdw3GpN1MwGqKP5nBiS1DutLjl7AivyCA7n/O1aMdm OtFffR908aaXaSdttxQ1L4Uo4PNVnq+X5mM4oA7U8LUtR4mgI+wBouVyU3c6wagabvGo pEYayasitQLp7Qq9rw5DhbmZTlQMyxHL+2BtjDpiuUQJo1m3VA1y5XKaKqOUJVqNxDJs spUgzA0pE62ScrriaOS5mpj8EuGhoknFWQcb+lFrYSSmZ9zR+NJ3Ei31f5F9DFM+X2mI LrxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=URnaX0QD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l13-20020a17090aaa8d00b001df458aec1bsi15360080pjq.93.2022.07.24.23.28.33; Sun, 24 Jul 2022 23:28:47 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=URnaX0QD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229886AbiGYGC7 (ORCPT + 99 others); Mon, 25 Jul 2022 02:02:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42528 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229821AbiGYGC6 (ORCPT ); Mon, 25 Jul 2022 02:02:58 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CB5B7646 for ; Sun, 24 Jul 2022 23:02:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1658728977; x=1690264977; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=xMvvaH+s6vqY1Iy3PvmDnSThXUYdc1gpUxDXwIleWbw=; b=URnaX0QDvIDZm2ua66tZSnxldCO8qIFn9xUq7wwhrtMMn2N8+zkwaG5P 8q2eB/c5qou6b4W1LgHXHXu1j5Vr9O6QiirsoSmFvsjU3+5YmC9sdDUUy 6GYuoG7kqD4sAuEikSxhfcVeVCeGTLPcG2/nuJfdMN6nfHoNz1h+X6cWM vn+P1/lOA0kWFjQHEmy28aKq8qQ0rxw4OgvUWIP2zP4vpDpk8s5boH0H9 HQiuaXLEDPUHOCfkbr7VXpL3Utl+rlsTMmW/6syqZuyokiZ9flXNcpHmE v8gVa412yIYWChIldSiMXTYUiUFjse3gqpY6TrbyCEphWFeALhfDJaCy5 A==; X-IronPort-AV: E=McAfee;i="6400,9594,10418"; a="351614349" X-IronPort-AV: E=Sophos;i="5.93,192,1654585200"; d="scan'208";a="351614349" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2022 23:02:57 -0700 X-IronPort-AV: E=Sophos;i="5.93,192,1654585200"; d="scan'208";a="574913607" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.239.13.94]) by orsmga006-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2022 23:02:53 -0700 From: "Huang, Ying" To: Jonathan Cameron Cc: Wei Xu , Aneesh Kumar K V , Johannes Weiner , "Linux MM" , Andrew Morton , "Yang Shi" , Davidlohr Bueso , Tim C Chen , Michal Hocko , "Linux Kernel Mailing List" , Hesham Almatary , Dave Hansen , "Alistair Popple" , Dan Williams , Subject: Re: [PATCH v8 00/12] mm/demotion: Memory tiers and demotion References: <20220704070612.299585-1-aneesh.kumar@linux.ibm.com> <87r130b2rh.fsf@yhuang6-desk2.ccr.corp.intel.com> <60e97fa2-0b89-cf42-5307-5a57c956f741@linux.ibm.com> <87r12r5dwu.fsf@yhuang6-desk2.ccr.corp.intel.com> <0a55e48a-b4b7-4477-a72f-73644b5fc4cb@linux.ibm.com> <87mtde6cla.fsf@yhuang6-desk2.ccr.corp.intel.com> <87ilo267jl.fsf@yhuang6-desk2.ccr.corp.intel.com> <87edyp67m1.fsf@yhuang6-desk2.ccr.corp.intel.com> <875yk15svi.fsf@yhuang6-desk2.ccr.corp.intel.com> <20220719150032.000066a6@Huawei.com> Date: Mon, 25 Jul 2022 14:02:49 +0800 In-Reply-To: <20220719150032.000066a6@Huawei.com> (Jonathan Cameron's message of "Tue, 19 Jul 2022 15:00:32 +0100") Message-ID: <878rohzq46.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 X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Jonathan, Jonathan Cameron writes: > On Wed, 13 Jul 2022 16:17:21 +0800 > "Huang, Ying" wrote: > >> Wei Xu writes: [snip] >> > >> > Th "memory type" and "abstract distance" concepts sound to me similar >> > to the memory tier "rank" idea. >> >> Yes. "abstract distance" is similar as "rank". >> >> > We can have some well-defined type/distance/rank values, e.g. HBM, >> > DRAM, CXL_DRAM, PMEM, CXL_PMEM, which a device can register with. The >> > memory tiers will build from these values. It can be configurable to >> > whether/how to collapse several values into a single tier. >> >> The memory types are registered by drivers (such as kmem_dax). And the >> distances can come from SLIT, HMAT, and other firmware or driver >> specific information sources. >> >> Per my understanding, this solution may make memory tier IDs more >> unstable. For example, the memory ID of a node may be changed after the >> user override the distance of a memory type. Although I think the >> overriding should be a rare operations, will it be a real issue for your >> use cases? > > Not sure how common it is, but I'm aware of systems that have dynamic > access characteristics. i.e. the bandwidth and latency of a access > to a given memory device will change dynamically at runtime (typically > due to something like hardware degradation / power saving etc). Potentially > leading to memory in use needing to move in 'demotion order'. We could > handle that with a per device tier and rank that changes... > > Just thought I'd throw that out there to add to the complexity ;) > I don't consider it important to support initially but just wanted to > point out this will only get more complex over time. > Thanks for your information! If we make the mapping from the abstract distance range to the memory tier ID stable at some degree, the memory tier ID can be stable at some degree, e.g., abstract distance range memory tier ID 1 -100 0 101-200 1 201-300 2 301-400 3 401-500 4 500- 5 Then if the abstract distance of a memory device changes at run time, its memory tier ID will change. But the memory tier ID of other memory devices can be unchanged. If so, the memory tier IDs are unstable mainly when we change the mapping from the abstract distance range to memory tier ID. Best Regards, Huang, Ying