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 5FA82C25B0E for ; Wed, 17 Aug 2022 01:04:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B09378D0001; Tue, 16 Aug 2022 21:04:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AB8106B0074; Tue, 16 Aug 2022 21:04:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 959168D0001; Tue, 16 Aug 2022 21:04:47 -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 85F276B0073 for ; Tue, 16 Aug 2022 21:04:47 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5BE0B1414A6 for ; Wed, 17 Aug 2022 01:04:47 +0000 (UTC) X-FDA: 79807289814.06.4E14BF2 Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by imf29.hostedemail.com (Postfix) with ESMTP id 363371201D0 for ; Wed, 17 Aug 2022 01:04:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1660698286; x=1692234286; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=mfUla04m6g9OuMl10lBVITDIZq8OhojlyKzQdm/DDNg=; b=KL7RCCJCBvRGkcQFxbyJDZP9Ev4ZJf+Ubv6KRo1AzdiovX3m6PA3IuVO L9PvCLHXSunNt7Alt03/CXbLn1cZkL0fJQWvzFGxl8tvJk3Oy4eaPEdxs cWbXQ360kLX55REaZv1JssfPi0vuSlC0QUkVEHUllL65HVGKmYtTVo9tA LOJLQbV0r5a5ck6JPZ+p2gUTegmIEWu9IhQfaZ+7/IyI0CcW77X9UpGX+ wXAu5fBQCo1d8HqyWyHrwuobZK5wkj+VZTwyzlaOpaDKaoV6P0pQmXZIW vy8EVBYJk2HXC+7dkM32JBZ/CUT5Vja7f2Q7kyfhwcKJj8Mj8G5XrH0nw A==; X-IronPort-AV: E=McAfee;i="6400,9594,10441"; a="292364492" X-IronPort-AV: E=Sophos;i="5.93,242,1654585200"; d="scan'208";a="292364492" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2022 18:02:18 -0700 X-IronPort-AV: E=Sophos;i="5.93,242,1654585200"; d="scan'208";a="696581283" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Aug 2022 18:02:14 -0700 From: "Huang, Ying" To: Bharata B Rao Cc: huang ying , Aneesh Kumar K V , , , Wei Xu , Yang Shi , Davidlohr Bueso , Tim C Chen , Michal Hocko , Linux Kernel Mailing List , Hesham Almatary , Dave Hansen , Jonathan Cameron , Alistair Popple , "Dan Williams" , Johannes Weiner , Subject: Re: [PATCH v14 04/10] mm/demotion/dax/kmem: Set node's abstract distance to MEMTIER_DEFAULT_DAX_ADISTANCE In-Reply-To: <57a091a5-a78f-7977-3413-11260501f8c0@amd.com> (Bharata B. Rao's message of "Tue, 16 Aug 2022 20:15:55 +0530") References: <20220812055710.357820-1-aneesh.kumar@linux.ibm.com> <20220812055710.357820-5-aneesh.kumar@linux.ibm.com> <87wnbacjsh.fsf@yhuang6-desk2.ccr.corp.intel.com> <57a091a5-a78f-7977-3413-11260501f8c0@amd.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Wed, 17 Aug 2022 09:02:04 +0800 Message-ID: <877d37d6nn.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ascii ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660698287; a=rsa-sha256; cv=none; b=v1tGCADSg3mbAcQ5FTKEUt31/tZPQ9dQnmGn28boQirXTWQsmRBNGfEju67GZ1nsA5yXaN Am4rbulXHtL0dYnV77/wLwaa2+k31VM4TTs8Ysb/Qunx/6CBXbn6qQpe9tpZkur6SelSlC rBf+iLJONYH8pFtv5cS4M04bdLb+x2Y= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KL7RCCJC; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 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=1660698287; 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=MHiVS/JzkZE8WAFGvkxU73rOwPSxwNroaOYTLVHEoYU=; b=NTgiJLxQn2K2xDhghuCdmsI4o/xbL8oTFWL7lLQex1VJBds1R++t0eQUaf/U9nRrZYA/cl SVoZYnk3V4bK3eQuxOh07azSeOJYP5PpvbP0ORzXX6ukn7by5uoqhFDplVODjsUCQLsNoj m8cxFihAw6P1RnTmZDw5KZOH+cQTC4I= X-Stat-Signature: 7auj1x9wpwwndg53mbdf8amjhodk1upg X-Rspamd-Queue-Id: 363371201D0 Authentication-Results: imf29.hostedemail.com; dkim=none ("invalid DKIM record") header.d=intel.com header.s=Intel header.b=KL7RCCJC; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf29.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.115 as permitted sender) smtp.mailfrom=ying.huang@intel.com X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1660698285-162859 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: Bharata B Rao writes: > On 8/16/2022 1:56 PM, huang ying wrote: > >>>> >>>> If my understanding were correct, you are suggesting to use a kind of >>>> logarithmic mapping from latency to abstract distance? That is, >>>> >>>> abstract_distance = log2(latency) >>>> >>>> While I am suggesting to use a kind of linear mapping from latency to >>>> abstract distance. That is, >>>> >>>> abstract_distance = C * latency >>>> >>>> I think that linear mapping is easy to understand. >>>> >>>> Are there some good reasons to use logarithmic mapping? >>> >>> Also, what is the recommendation for using bandwidth measure which >>> may be available from HMAT for CXL memory? How is bandwidth going >>> to influence the abstract distance? >> >> This is a good question. >> >> Per my understanding, latency stands for idle latency by default. But >> in practice, the latency under some reasonable memory accessing >> throughput is the "real" latency. So the memory with lower bandwidth >> should have a larger abstract distance than the memory with higher >> bandwidth even if the idle latency is the same. But I don't have a >> perfect formula to combine idle latency and bandwidth into abstract >> distance. One possibility is to increase abstract distance if the >> bandwidth of the memory is much lower than that of DRAM. > > So if the firmware/platforms differ in their definition of latency and > bandwidth (like idle vs real value etc) in the firmware tables > (like HMAT), then the low level drivers (like ACPI) would have to be > aware of these and handle the conversion from latency and bw to > abstract distance correctly? One possible way to make this a little easier is that we plan to add a knob (as user space interface via sysfs) for each memory type, so that the default abstract distance can be offset. If so, at least we have way to deal with difference in firmware/platforms. Best Regards, Huang, Ying