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 F15DEC4345F for ; Wed, 17 Apr 2024 08:54:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 470DF6B0087; Wed, 17 Apr 2024 04:54:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 420736B0088; Wed, 17 Apr 2024 04:54:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2E8396B0089; Wed, 17 Apr 2024 04:54:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 104BA6B0087 for ; Wed, 17 Apr 2024 04:54:01 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8B0E2121105 for ; Wed, 17 Apr 2024 08:54:00 +0000 (UTC) X-FDA: 82018411440.15.F7066A2 Received: from mail-yb1-f182.google.com (mail-yb1-f182.google.com [209.85.219.182]) by imf13.hostedemail.com (Postfix) with ESMTP id BF15D2000F for ; Wed, 17 Apr 2024 08:53:57 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=PkHnNDXf; spf=pass (imf13.hostedemail.com: domain of horenchuang@bytedance.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=horenchuang@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713344038; 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=OGwSiMzvAKR+bq3SRViWE8ZoGbeuRmJT21WPOyLk3/o=; b=OKxF8QT792d7wdX9x8NeswMqPVDMGa7hJbKUQ62LvD02x7HwAuhg8AF1lv53LptKsm9eA2 cXgfgbp1t1pjWkXoPSlHTpEGqOkYqKKWiBB1AlrhbdAh48ObPcjeUcS7ObHFEgOEEGZcSl BCXmqeaq6DLHASc+OzTaa54gDqNALLU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713344038; a=rsa-sha256; cv=none; b=5uVl68KubIQZMlcULK0i5qppVi2ZMKWPbHzLuqpUh1bfmDcHj/CR/lsWwM6eCPt9FJV4zj WOj9HYKNPZQwkQacu9Vs7rnqgcsaj2nG2TE1dnPvjW51nWUp0o3MSppO/BEY7adDOZVfFm DzcLk0u5AsyRKrwaI9Gp+KcSDHKW8L0= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=bytedance.com header.s=google header.b=PkHnNDXf; spf=pass (imf13.hostedemail.com: domain of horenchuang@bytedance.com designates 209.85.219.182 as permitted sender) smtp.mailfrom=horenchuang@bytedance.com; dmarc=pass (policy=quarantine) header.from=bytedance.com Received: by mail-yb1-f182.google.com with SMTP id 3f1490d57ef6-dd10ebcd702so5046352276.2 for ; Wed, 17 Apr 2024 01:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1713344036; x=1713948836; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=OGwSiMzvAKR+bq3SRViWE8ZoGbeuRmJT21WPOyLk3/o=; b=PkHnNDXflLQ0NUG/eTlpWP69n1GZnKotvyLgxI3i1rpDEiFqZcZfLiuppXnoj3WsKa QfIZG+qBh6vFXIpRycVbG+q6L/c4Q5vqUhMthR8pXbd30v3EzrJnxhs/zBWBV9cp1q0z jYYOVdT7fh+/0N1j2gUX3I5Z8XDlks9yJcZeH5DIcZsBGhq1vSrcXzujgMsWxjkDRX61 uhNugGgibCKSYZl9WEila9kHI5MLdPuiDLGxlmHGFa9HcCLG1dMSrVpmrx7vBuBfgxOs MX4HmbmVTrODtxjfvSRASRT+WHMHx/WS/VGLzTRIyhvknND9yNi5Aefn+Bhpvzjb+trj 5VSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713344036; x=1713948836; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=OGwSiMzvAKR+bq3SRViWE8ZoGbeuRmJT21WPOyLk3/o=; b=Dmu3ewniQKxlwYXcmgDtbAVyvOTTuF+9Q7YTNLwoHaSQa6MXxAQyy5mlcvTssyZe1R XdJCmsq82ZXZu1c8zdEBkueAI+vZADVfIwlpUKMwRbF/9Oe0m7hi0hoyEs8TqjocdBUg InrWfMCrOLortlL2fG3xpbEddiNVi2UxROKrKgdFrxITUCrtOolJcsAbUhphC9xAvF+2 3nTzwmTMVhBXZ09mVj0AT2dsLwQ6tCP0f+vCF8oChBpIIqB5RKgqvBfiE6F8JEUxggLs 3D8llrfGvlxAu4TiCBsQvT9Fj0UBCw/X3bO23hi/2wqlJ+ITpHwLd58sIi382El0USI2 bMUw== X-Forwarded-Encrypted: i=1; AJvYcCXYPD29m6JAIJlWBm3hxT7bo19d+brsaE9T0BpJoMwR1Y5FoVulAdCXFlNeL1Qv0pP5t/3C94esr+sCYCFIu6f+Q0Q= X-Gm-Message-State: AOJu0Yz561boOZHlNh4mWq6b3oeupvEiKH5xNt1wlz5JK1CbSHhgXxoL FiNuwsPV77FAv2g+0cBSQt4+INSOoEuYZo+189fCjVOwycw2J9tQbnubs3M4wNUolt03P3S0re5 ugUn6Vsx6QzuCSZPz+V2XAQ2TGb4TjU2vKZv6Tw== X-Google-Smtp-Source: AGHT+IFZRZdQbGM2QETddK5D0uyMD/72MA62SJVOkINntmHAAG+laCqSBzT6nP80eg1XWB0b95YnHzUb7Sadw2HRYNM= X-Received: by 2002:a25:ac42:0:b0:de4:2bc:c715 with SMTP id r2-20020a25ac42000000b00de402bcc715mr4797289ybd.8.1713344036496; Wed, 17 Apr 2024 01:53:56 -0700 (PDT) MIME-Version: 1.0 References: <20240405000707.2670063-1-horenchuang@bytedance.com> <20240405000707.2670063-3-horenchuang@bytedance.com> <20240405150244.00004b49@Huawei.com> <20240409171204.00001710@Huawei.com> <20240410175114.00001e1e@Huawei.com> In-Reply-To: <20240410175114.00001e1e@Huawei.com> From: "Ho-Ren (Jack) Chuang" Date: Wed, 17 Apr 2024 01:53:45 -0700 Message-ID: Subject: Re: [External] Re: [PATCH v11 2/2] memory tier: create CPUless memory tiers after obtaining HMAT info To: Jonathan Cameron Cc: "Huang, Ying" , Gregory Price , aneesh.kumar@linux.ibm.com, mhocko@suse.com, tj@kernel.org, john@jagalactic.com, Eishan Mirakhur , Vinicius Tavares Petrucci , Ravis OpenSrc , Alistair Popple , Srinivasulu Thanneeru , SeongJae Park , Dan Williams , Vishal Verma , Dave Jiang , Andrew Morton , nvdimm@lists.linux.dev, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, Linux Memory Management List , "Ho-Ren (Jack) Chuang" , "Ho-Ren (Jack) Chuang" , qemu-devel@nongnu.org, Hao Xiang Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: BF15D2000F X-Stat-Signature: 9xs9h4ztr1znhbe59c5uqhr8e8467nd9 X-Rspam-User: X-HE-Tag: 1713344037-965993 X-HE-Meta: U2FsdGVkX19P+qDkpTONYTce4aFfcAZAQwNNhiQQ4TMZZZzeGfNNQw1t6byzLuEr80qXP4pMZiWOGd8jEJFm+Ag6CwZcLkghnjD79iyRHT3KWfY2ZHjFd5jgRBjqb5NDHjzxw1oPJOHS+9LSDAMd7FpQaGG7tn41FSbVZA8lMeR7fgWp9AXEH9h96bj7r3QARey22yGTSdSoZpxFCTGkh4ysKO5sKtULu7RbAPccIqqt78u4BOKyQKQukO77g1hoaHfZVUBoKgFkz4HdZuJlol7q8LQZ5W/F7gE3N+VgC+bgktzGV/PV5QhR7SO8Cowner1RthePuFq4hv+BWMj6NbOb1RRP19PCAEtZPEfo6Z2IQQc0J3XwxtdIGoZ5Gp1WhXL66qK1ZFyb/vusI4gNo8exO/ENMGXkA5Xn4kQzJTrOW/8UlOa8e5UOUVhwlMN/wjRFihqNX2kr7PsB/kZJLUfq6pIPw5N0KlM4k8OhfKGPG38tt/EJjnjY9Ggf6W6E5bqxToldjOja5P7VqQXv28z6tpEIgkEZhSiJKAZln4RmW9FeeWFsMn46RH06nh4ZXt88uXtkEC297WgYhghUlkLM95HL1fzptp74ByE8NycP89ZcB1nni9LjlWxuBcBIJRWXuo8lNgk/ajj3GFzkNXMf7xt0uvWFPmVxMfVbpPp/vDiyTZmyPtpPHqAjAP9lESOxDAvIDJklVmHLBMlCY4gR3lzqAgAtGqLXzQqDm4Au/EAM+/V2bOQBUI3NPDIu75dzhxAsZp4DCQAoZQcsS288nyE5DthioUErwt6VlL4qsr897CNztUj9GF3tnoINRJdF+xEvjrJQn8csDQYvL57W8vyEI1h1yLs7aRj7TjHR380CxXHN27S2h6NcQfZrmJlBIbDucVd3D4xeFV8pZ68TMx2wqrC3YVTcWvlSZbHP4jZXwbSG8p1o01Lx1H1WD5hd/eqjB0bpaFYIDkD 0gJsQsgr ZPA0eL+rjxfIlFs+jChXBx5wSmnC/63iaCwJSg9A7NFavTI5xiLTILjccj5L2GLIVPUwvHLdTXsGEGNqEytutedmir0rQSBuaNFDfaoQMMNdSVs7KoGRXeQIUMOsNzKi3AcPSgaYuddMU2KTL693KjxaHV+arXw40B8n/Yq0vlfPKqY0/KPQ1TrwmyRnsLBoxe0PWAL9dGzLyOWeAJ1/9feOGcr0/UwK+AMaY0PjWQOU7Cw/KW05Sd/CmjLP0fr05QC5ZNFqdQNmC59hQCy72BdPfoXhsqrllB1IgzED82xvQ2B7jLLb9+T6J8EuwK0zEp5jRZO5I02LUvsl7+vAIHiwzNKDS4JOlaUreIkYSokgcXUQoZkDahu2dGMKnZMeWjtvvH4a/3JLrh2KuD+z+nTjFaAdtYXAy81P0/2QWYZAm4u4= 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 Wed, Apr 10, 2024 at 9:51=E2=80=AFAM Jonathan Cameron wrote: > > On Tue, 9 Apr 2024 12:02:31 -0700 > "Ho-Ren (Jack) Chuang" wrote: > > > Hi Jonathan, > > > > 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: > > > > > > > On Fri, Apr 5, 2024 at 7:03=E2=80=AFAM Jonathan Cameron > > > > wrote: > > > > > > > > > > On Fri, 5 Apr 2024 00:07:06 +0000 > > > > > "Ho-Ren (Jack) Chuang" wrote: > > > > > > > > > > > The current implementation treats emulated memory devices, such= as > > > > > > CXL1.1 type3 memory, as normal DRAM when they are emulated as n= ormal 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 initializat= ion process > > > > > > to introduce a delay specifically for CPUless NUMA nodes. This = delay > > > > > > ensures that the memory tier initialization for these nodes is = deferred > > > > > > until HMAT information is obtained during the boot process. Fin= ally, > > > > > > 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= bringing > > > > > > online memory nodes and configuring memory tiers. They should b= e excluded > > > > > > in the late init. > > > > > > > > > > > > * Handle cases where there is no HMAT when creating memory tier= s > > > > > > There is a scenario where a CPUless node does not provide HMAT = information. > > > > > > If no HMAT is specified, it falls back to using the default DRA= M tier. > > > > > > > > > > > > * Introduce another new lock `default_dram_perf_lock` for adist= calculation > > > > > > In the current implementation, iterating through CPUlist nodes = requires > > > > > > holding the `memory_tier_lock`. However, `mt_calc_adistance()` = will end up > > > > > > trying to acquire the same lock, leading to a potential deadloc= k. > > > > > > Therefore, we propose introducing a standalone `default_dram_pe= rf_lock` to > > > > > > protect `default_dram_perf_*`. This approach not only avoids de= adlock > > > > > > but also prevents holding a large lock simultaneously. > > > > > > > > > > > > * Upgrade `set_node_memory_tier` to support additional cases, i= ncluding > > > > > > 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_t= ier()` to > > > > > > handle cases where memtype is not initialized and where HMAT in= formation is > > > > > > available. > > > > > > > > > > > > * Introduce `default_memory_types` for those memory types that = are not > > > > > > initialized by device drivers. > > > > > > Because late initialized memory and default DRAM memory need to= be managed, > > > > > > a default memory type is created for storing all memory types t= hat 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" > > > > > > > > > > Hi - one remaining question. Why can't we delay init for all node= s > > > > > to either drivers or your fallback late_initcall code. > > > > > It would be nice to reduce possible code paths. > > > > > > > > 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 patchs= et. > > > > > > > > After tier_mem(), hmat_init() is called, which requires registering > > > > `default_dram_type` info. This is when `default_dram_type` is neede= d. > > > > 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? > > > > > > 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 > > > > 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. Hi Jonathan, Thank you and I will do! Could you please take another look and see if there are any further changes needed for this patchset? If everything looks good to you, could you please also provide a 'Reviewed-by' for this patch? Per discussion, I'm going to prepare another patchset "memory tier initialization path optimization" and will send it out once ready. > > Jonathan --=20 Best regards, Ho-Ren (Jack) Chuang =E8=8E=8A=E8=B3=80=E4=BB=BB