linux-kernel - Re: [PATCH v3] memory tier: consolidate the initialization of memory tiers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240704181054.00001f67@Huawei.com>
Date: Thu, 4 Jul 2024 18:10:54 +0100
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: "Ho-Ren (Jack) Chuang" <horen.chuang@...ux.dev>
CC: "Huang, Ying" <ying.huang@...el.com>, Gregory Price
	<gourry.memverge@...il.com>, <aneesh.kumar@...ux.ibm.com>, <mhocko@...e.com>,
	<tj@...nel.org>, <john@...alactic.com>, Eishan Mirakhur
	<emirakhur@...ron.com>, Vinicius Tavares Petrucci <vtavarespetr@...ron.com>,
	Ravis OpenSrc <Ravis.OpenSrc@...ron.com>, Alistair Popple
	<apopple@...dia.com>, Srinivasulu Thanneeru <sthanneeru@...ron.com>, SeongJae
 Park <sj@...nel.org>, "Rafael J. Wysocki" <rafael@...nel.org>, Len Brown
	<lenb@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>, Dave Jiang
	<dave.jiang@...el.com>, "Dan Williams" <dan.j.williams@...el.com>,
	<linux-acpi@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-mm@...ck.org>, "Ho-Ren (Jack) Chuang" <horenc@...edu>, "Ho-Ren (Jack)
 Chuang" <horenchuang@...edance.com>, "Ho-Ren (Jack) Chuang"
	<horenchuang@...il.com>, <linux-cxl@...r.kernel.org>, <qemu-devel@...gnu.org>
Subject: Re: [PATCH v3] memory tier: consolidate the initialization of
 memory tiers

On Thu,  4 Jul 2024 07:26:44 +0000
"Ho-Ren (Jack) Chuang" <horen.chuang@...ux.dev> wrote:

> The current memory tier initialization process is distributed across
> two different functions, memory_tier_init() and memory_tier_late_init().
> This design is hard to maintain. Thus, this patch is proposed to reduce
> the possible code paths by consolidating different
> initialization patches into one.
> 
> The earlier discussion with Jonathan and Ying is listed here:
> https://lore.kernel.org/lkml/20240405150244.00004b49@Huawei.com/
> 
> If we want to put these two initializations together, they must be
> placed together in the later function. Because only at that time,
> the HMAT information will be ready, adist between nodes can be
> calculated, and memory tiering can be established based on the adist.
> So we position the initialization at memory_tier_init() to the
> memory_tier_late_init() call. Moreover, it's natural to keep
> memory_tier initialization in drivers at device_initcall() level.
> 
> If we simply move the set_node_memory_tier() from memory_tier_init()
> to late_initcall(), it will result in HMAT not registering
> the mt_adistance_algorithm callback function, because
> set_node_memory_tier() is not performed during the memory tiering
> initialization phase, leading to a lack of correct default_dram
> information.
> 
> Therefore, we introduced a nodemask to pass the information of the
> default DRAM nodes. The reason for not choosing to reuse
> default_dram_type->nodes is that it is not clean enough. So in the end,
> we use a __initdata variable, which is a variable that is released once
> initialization is complete, including both CPU and memory nodes for HMAT
> to iterate through.
> 
> This patchset is based on commits <cf93be18fa1b> ("memory tier: create
> CPUless memory tiers after obtaining HMAT info") and
> <a72a30af550c> ("memory tier: dax/kmem: introduce an abstract layer for
> finding, allocating, and putting memory types"):
> [0/2] https://lkml.kernel.org/r/20240405000707.2670063-1-horenchuang@bytedance.com
> [1/2] https://lkml.kernel.org/r/20240405000707.2670063-2-horenchuang@bytedance.com
> [1/2] https://lkml.kernel.org/r/20240405000707.2670063-3-horenchuang@bytedance.com
> 
> Signed-off-by: Ho-Ren (Jack) Chuang <horenchuang@...edance.com>
> Suggested-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>
LGTM
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@...wei.com>