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 7A22FC43334 for ; Tue, 26 Jul 2022 12:00:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF9F78E0002; Tue, 26 Jul 2022 08:00:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA9428E0001; Tue, 26 Jul 2022 08:00:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A707C8E0002; Tue, 26 Jul 2022 08:00:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 999D48E0001 for ; Tue, 26 Jul 2022 08:00:25 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 1D32AC11D3 for ; Tue, 26 Jul 2022 12:00:25 +0000 (UTC) X-FDA: 79729108410.11.526C339 Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by imf22.hostedemail.com (Postfix) with ESMTP id 21089C009E for ; Tue, 26 Jul 2022 12:00:22 +0000 (UTC) Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 26QAV9Ar027515; Tue, 26 Jul 2022 12:00:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=pUJ9hVGmoW1g5dUuSJMrZiPBT3Gn9gvcys//WFaFVdc=; b=XMaSkbLJWsVoaQU6q6X752BIomSxVd2UJG9ojXDdFG73NrVfk+gb5aqh9a7C9tbuOjyK S2aWUzZnwXYL23Xlm0byqycVsQTkozgBMTGx3CBlEGJ+5Rt+OjHEtS249bxty4od1ju9 BNjaPwjcL059sU2sWcncaU5tSHsGpSG8p7Ibmhu99dSrvuIz+6Hh/FKmLGoZWd5YlRDE yY3oh/tLNJVivydrH4JOssmT6O5fq3vJPhYd7eC43uEUQTidPlbZyCRYp+iLc1h5K8CB 6G1jJhaPszH/0gYTLJrSyFeSjc86taSnqeRNQwAo2c609XRix741furQMjwYd2ESlA1f BA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hjcq2x1hb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 12:00:07 +0000 Received: from m0098399.ppops.net (m0098399.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 26QBifIq013547; Tue, 26 Jul 2022 12:00:07 GMT Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3hjcq2x1ef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 12:00:06 +0000 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 26QBq8wU005557; Tue, 26 Jul 2022 12:00:03 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma06fra.de.ibm.com with ESMTP id 3hg98fhbjh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Jul 2022 12:00:03 +0000 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 26QC00QR20513262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 26 Jul 2022 12:00:00 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D165542041; Tue, 26 Jul 2022 12:00:00 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 0F1FD4203F; Tue, 26 Jul 2022 11:59:57 +0000 (GMT) Received: from [9.43.64.160] (unknown [9.43.64.160]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 26 Jul 2022 11:59:56 +0000 (GMT) Message-ID: <9e9ba2e4-3a87-3a79-e336-8849dad4856a@linux.ibm.com> Date: Tue, 26 Jul 2022 17:29:56 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v10 1/8] mm/demotion: Add support for explicit memory tiers Content-Language: en-US To: "Huang, Ying" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, 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 , jvgediya.oss@gmail.com, Jagdish Gediya References: <20220720025920.1373558-1-aneesh.kumar@linux.ibm.com> <20220720025920.1373558-2-aneesh.kumar@linux.ibm.com> <87k080wmvb.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Aneesh Kumar K V In-Reply-To: <87k080wmvb.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 6y-OBH2B61fOSCTU1nTn3MeBZEcvUzei X-Proofpoint-GUID: 4ya5gc6aGV8hUKqHfsCN-R6E9lFp-wQW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.883,Hydra:6.0.517,FMLib:17.11.122.1 definitions=2022-07-26_04,2022-07-26_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 phishscore=0 spamscore=0 priorityscore=1501 clxscore=1015 mlxscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2206140000 definitions=main-2207260043 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658836823; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pUJ9hVGmoW1g5dUuSJMrZiPBT3Gn9gvcys//WFaFVdc=; b=VwYFzFsBW4PejVaFH9tXCfGm2BdBGeDvC808eWVFGyu0JjR4LZxJLmaOLb5DpmImZ1tSq+ MZKueVEvTLBdN1kJ++Lrn9amdNekKlg679Q7xzzHpvsiErIJSCnLVVTAeoABZm4o7AMpCo MN9+AhNF/4lYXkNVn9RoK41taSXr5yE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658836823; a=rsa-sha256; cv=none; b=Hoal4SCkhlH3SyQ15zmg/cRdM2U+V0tbb1yABltedJNhfIe+2rNSSOAufRXYv5+MGDgquu KAd9JPOY4QnaadbsiS0SzDEISTQzqZqr8fN7uwln29gkcCi6QekOoQYQ07Sk1fZvJCXKDx 9p2a1zKjd+d2vRtB/C+klhlWiHj35bU= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=XMaSkbLJ; spf=pass (imf22.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=ibm.com header.s=pp1 header.b=XMaSkbLJ; spf=pass (imf22.hostedemail.com: domain of aneesh.kumar@linux.ibm.com designates 148.163.156.1 as permitted sender) smtp.mailfrom=aneesh.kumar@linux.ibm.com; dmarc=pass (policy=none) header.from=ibm.com X-Rspam-User: X-Rspamd-Queue-Id: 21089C009E X-Rspamd-Server: rspam05 X-Stat-Signature: 9td1yhuwzkwjxor8iu648bdhfqracycy X-HE-Tag: 1658836822-803741 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: >> diff --git a/include/linux/node.h b/include/linux/node.h >> index 40d641a8bfb0..a2a16d4104fd 100644 >> --- a/include/linux/node.h >> +++ b/include/linux/node.h >> @@ -92,6 +92,12 @@ struct node { >> struct list_head cache_attrs; >> struct device *cache_dev; >> #endif >> + /* >> + * For memory devices, perf_level describes >> + * the device performance and how it should be used >> + * while building a memory hierarchy. >> + */ >> + int perf_level; > > Think again, I found that "perf_level" may be not the best abstraction > of the performance of memory devices. In concept, it's an abstraction of the memory > bandwidth. But it will not reflect the memory latency. > > Instead, the previous proposed "abstract_distance" is an abstraction of > the memory latency. Per my understanding, the memory latency has more > direct influence on system performance. And because the latency of the > memory device will increase if the memory accessing throughput nears its > max bandwidth, so the memory bandwidth can be reflected in the "abstract > distance" too. That is, the "abstract distance" is an abstraction of > the memory latency under the expected memory accessing throughput. The > "offset" to the default "abstract distance" reflects the different > expected memory accessing throughput. > > So, I think we need some kind of abstraction of the memory latency > instead of memory bandwidth, e.g., "abstract distance". > I am reworking other parts of the patch set based on your feedback. This part I guess we need to reach some consensus. IMHO perf_level (performance level) can indicate a combination of both latency and bandwidth. It is an abstract concept that indicates the performance of the device. As we learn more about which device attribute makes more impact in defining hierarchy, performance level will give more weightage to that specific attribute. It could be write latency or bandwidth. For me, distance has a direct linkage to latency because that is how we define numa distance now. Adding abstract to the name is not making it more abstract than perf_level. I am open to suggestions from others. Wei Xu has also suggested perf_level name. I can rename this to abstract_distance if that indicates the goal better. -aneesh