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 7AB0DCD128A for ; Wed, 10 Apr 2024 16:51:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F17C66B0085; Wed, 10 Apr 2024 12:51:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EC7AF6B0087; Wed, 10 Apr 2024 12:51:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D8F716B0088; Wed, 10 Apr 2024 12:51:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B8FFE6B0085 for ; Wed, 10 Apr 2024 12:51:23 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 42A5E408A6 for ; Wed, 10 Apr 2024 16:51:23 +0000 (UTC) X-FDA: 81994212846.22.1B04F41 Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) by imf29.hostedemail.com (Postfix) with ESMTP id 42807120002 for ; Wed, 10 Apr 2024 16:51:20 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712767881; 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; bh=zrjbnxX9N0FrKNcItH8XBZYmPd6AVs5wgGyuTuKAujk=; b=K+Qekb+XqHmvR3zmyYLRb1mrehmCHvS2NUb6j9uhWRPpEunA3lBn/xM+YofvoL6qvdA5eH ttHmDXUkgH6x8TMzFe1ygVT2JB4rJkxyHzXsSawGxb0+PZeVgfucuHZIAx0+SlWtl6AjAx pSDDhvBonFC5S0VSL0rzQYK1/CA+6jM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712767881; a=rsa-sha256; cv=none; b=BADviQ3rqdJHUcB+spCOlknF6AWpQ1M9KF1Npe4jnD4cEJn6BeRyYXiL3G5uzf3D81nNj0 kbvms9tZdBwVNVG0Ybpn9zUkQeUue7+6flj8/ATJ7uBv5sw7tA5i/wMY61UiqKB263eUFO NF36zrhZFOgwf9q7WvWXRt4P0nvnNIQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of jonathan.cameron@huawei.com designates 185.176.79.56 as permitted sender) smtp.mailfrom=jonathan.cameron@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VF81s3HTwz67fw4; Thu, 11 Apr 2024 00:49:37 +0800 (CST) Received: from lhrpeml500005.china.huawei.com (unknown [7.191.163.240]) by mail.maildlp.com (Postfix) with ESMTPS id AAC89140D26; Thu, 11 Apr 2024 00:51:15 +0800 (CST) Received: from localhost (10.202.227.76) by lhrpeml500005.china.huawei.com (7.191.163.240) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.35; Wed, 10 Apr 2024 17:51:15 +0100 Date: Wed, 10 Apr 2024 17:51:14 +0100 From: Jonathan Cameron To: "Ho-Ren (Jack) Chuang" CC: "Huang, Ying" , Gregory Price , , , , , Eishan Mirakhur , Vinicius Tavares Petrucci , Ravis OpenSrc , Alistair Popple , Srinivasulu Thanneeru , SeongJae Park , Dan Williams , Vishal Verma , Dave Jiang , "Andrew Morton" , , , , "Linux Memory Management List" , "Ho-Ren (Jack) Chuang" , "Ho-Ren (Jack) Chuang" , , Hao Xiang Subject: Re: [External] Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info Message-ID: <20240410175114.00001e1e@Huawei.com> In-Reply-To: References: <20240405000707.2670063-1-horenchuang@bytedance.com> <20240405000707.2670063-3-horenchuang@bytedance.com> <20240405150244.00004b49@Huawei.com> <20240409171204.00001710@Huawei.com> Organization: Huawei Technologies Research and Development (UK) Ltd. X-Mailer: Claws Mail 4.1.0 (GTK 3.24.33; x86_64-w64-mingw32) MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.202.227.76] X-ClientProxiedBy: lhrpeml500003.china.huawei.com (7.191.162.67) To lhrpeml500005.china.huawei.com (7.191.163.240) X-Rspamd-Queue-Id: 42807120002 X-Rspam-User: X-Stat-Signature: 9135fju9k3yzthwwn8zceoboyfzdxx73 X-Rspamd-Server: rspam03 X-HE-Tag: 1712767880-531211 X-HE-Meta: U2FsdGVkX1/MPErITAeopM5+iZati6WnSP6tQcKibDW94ZSpxGB0uS5xHegIb8BYPrFTIH5oi+GE781TfCosstA3GWT8quyomMfzRC/nE9dUd85TVzwUITQSZKkO2qQ4rAMYXPhdFwNZT0jjauByUbc13DcuLYPzWP0yukVgofdS/9OE4WbetleWcc/9+TtkLW72WOEwEH6NOzuwT1pXV6slejHngujVrYhCJuns4w2OXg7f4r46kiBrcsSr4ZwJszdYBXTqRj1w0C8RXpy5by5l0/qnFg7wTf4mQWmD2JzfOEhVkBLPLCBMw4LShlf4FsoZoL3uk/IGxcwfBAKYHxaRioFpGTH1WCJjxrmH8RqAYxXCHckE7ITZUvqNUP1lPqbmgMH/iHT7s9oaXTkmP8ytCowQsr/K2zM05Qs3Bjb3LTurwmkrpNmh7/uYI2/uJTEGSSR2nPpVNLa65JfkbNSGXxy89Fi/EBZXnP8z7zxSKvwT3PTD/FV4sf9EsB3/xyJmv7uhgaQj1IoNI3YhlwXpNkPIBW3gBmUeH51jTMQw0SLUn1jWQLfiB7HGl99sYH3jx8/v80WLRAf1jb7u/BqBAbO6ANP/2xEN8iLLo2AnS3eLfv0bF2kIbywsr+U8aZV4SShbDZhtkrTtRE8GkXk2ECDmt4CWo/qNXm9XNU3SgWYBqKLyC65g1RRSHSu7n1ewDQ096I2Mpgjhb0/nric5+s5oKtRHUm6pKFxdGEQ8omEqPZF9rn3opIS6iuFT0Wr3i6E4i5O/BcUxL6sV3U49Np/OIBTDWfOM/Cq6IP28AW+xN8WHQ+ObGuZ3JtFvOBT8L7c/HkPKhoJS52Q7mcbpXbyO6iXchv65HGEDnEZ8cHXfmY1WaU+sRmK9onOwLjAGxFHKLaad8OIOqgLgXH2PmaHLZVlPb2dfE5HKnevpMDpVhlmNWMO5GyPzxQwzTYTHVSfzgElPHc53Npk j2/rIBVI 01Na1TVopIP2E0r12ji8BCjrhJK477MjJkVpmyK1ahdM4Wh+RLX/OZKOh83N0S+A/n4cK2CyYw7ZY6MKLgVtM6f7VbWqPaV59nv2GmYed+E4M2UWtXnjhDuV8u9b4/ULXua5yPqQjbP0Nm0nkxwsIepB/9MUcf8hs7AvgRGxUdnHPmCUK1736g1MwGbcErdBxiOK+GMDQRNjWLsmQmoGUaPB/lF2zsDlOt9raeAHrjHJsdj3Zpa1PlnouOW9h3pttEGszBQXOZEd3zfGWqxVKhctyKQfLqwrFAx0SybCs8y0qWh81pcRGDjPQUs5p2GE85CDluWOLxdR+AViaTsNVA8W3fMCd/VqD6Ihw5k7bPHoSxf/9AvSqQcVJxRf68l2MUynR 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: List-Subscribe: List-Unsubscribe: On Tue, 9 Apr 2024 12:02:31 -0700 "Ho-Ren (Jack) Chuang" wrote: > Hi Jonathan, >=20 > On Tue, Apr 9, 2024 at 9:12=E2=80=AFAM Jonathan Cameron > wrote: > > > > On Fri, 5 Apr 2024 15:43:47 -0700 > > "Ho-Ren (Jack) Chuang" wrote: > > =20 > > > On Fri, Apr 5, 2024 at 7:03=E2=80=AFAM Jonathan Cameron > > > wrote: =20 > > > > > > > > On Fri, 5 Apr 2024 00:07:06 +0000 > > > > "Ho-Ren (Jack) Chuang" wrote: > > > > =20 > > > > > The current implementation treats emulated memory devices, such as > > > > > CXL1.1 type3 memory, as normal DRAM when they are emulated as nor= mal memory > > > > > (E820_TYPE_RAM). However, these emulated devices have different > > > > > characteristics than traditional DRAM, making it important to > > > > > distinguish them. Thus, we modify the tiered memory initializatio= n process > > > > > to introduce a delay specifically for CPUless NUMA nodes. This de= lay > > > > > ensures that the memory tier initialization for these nodes is de= ferred > > > > > until HMAT information is obtained during the boot process. Final= ly, > > > > > demotion tables are recalculated at the end. > > > > > > > > > > * late_initcall(memory_tier_late_init); > > > > > Some device drivers may have initialized memory tiers between > > > > > `memory_tier_init()` and `memory_tier_late_init()`, potentially b= ringing > > > > > online memory nodes and configuring memory tiers. They should be = excluded > > > > > in the late init. > > > > > > > > > > * Handle cases where there is no HMAT when creating memory tiers > > > > > There is a scenario where a CPUless node does not provide HMAT in= formation. > > > > > If no HMAT is specified, it falls back to using the default DRAM = tier. > > > > > > > > > > * Introduce another new lock `default_dram_perf_lock` for adist c= alculation > > > > > In the current implementation, iterating through CPUlist nodes re= quires > > > > > holding the `memory_tier_lock`. However, `mt_calc_adistance()` wi= ll end up > > > > > trying to acquire the same lock, leading to a potential deadlock. > > > > > Therefore, we propose introducing a standalone `default_dram_perf= _lock` to > > > > > protect `default_dram_perf_*`. This approach not only avoids dead= lock > > > > > but also prevents holding a large lock simultaneously. > > > > > > > > > > * Upgrade `set_node_memory_tier` to support additional cases, inc= luding > > > > > default DRAM, late CPUless, and hot-plugged initializations. > > > > > To cover hot-plugged memory nodes, `mt_calc_adistance()` and > > > > > `mt_find_alloc_memory_type()` are moved into `set_node_memory_tie= r()` to > > > > > handle cases where memtype is not initialized and where HMAT info= rmation is > > > > > available. > > > > > > > > > > * Introduce `default_memory_types` for those memory types that ar= e not > > > > > initialized by device drivers. > > > > > Because late initialized memory and default DRAM memory need to b= e managed, > > > > > a default memory type is created for storing all memory types tha= t are > > > > > not initialized by device drivers and as a fallback. > > > > > > > > > > Signed-off-by: Ho-Ren (Jack) Chuang > > > > > Signed-off-by: Hao Xiang > > > > > Reviewed-by: "Huang, Ying" =20 > > > > > > > > Hi - one remaining question. Why can't we delay init for all nodes > > > > to either drivers or your fallback late_initcall code. > > > > It would be nice to reduce possible code paths. =20 > > > > > > I try not to change too much of the existing code structure in > > > this patchset. > > > > > > To me, postponing/moving all memory tier registrations to > > > late_initcall() is another possible action item for the next patchset. > > > > > > After tier_mem(), hmat_init() is called, which requires registering > > > `default_dram_type` info. This is when `default_dram_type` is needed. > > > However, it is indeed possible to postpone the latter part, > > > set_node_memory_tier(), to `late_init(). So, memory_tier_init() can > > > indeed be split into two parts, and the latter part can be moved to > > > late_initcall() to be processed together. > > > > > > Doing this all memory-type drivers have to call late_initcall() to > > > register a memory tier. I=E2=80=99m not sure how many they are? > > > > > > What do you guys think? =20 > > > > Gut feeling - if you are going to move it for some cases, move it for > > all of them. Then we only have to test once ;) > > > > J =20 >=20 > Thank you for your reminder! I agree~ That's why I'm considering > changing them in the next patchset because of the amount of changes. > And also, this patchset already contains too many things. Makes sense. (Interestingly we are reaching the same conclusion for the thread that motivated suggesting bringing them all together in the first place!) Get things work in a clean fashion, then consider moving everything to happen at the same time to simplify testing etc. Jonathan