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 CF36FC3DA61 for ; Mon, 29 Jul 2024 14:23:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6272A6B0095; Mon, 29 Jul 2024 10:23:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D7976B0096; Mon, 29 Jul 2024 10:23:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49FB56B0098; Mon, 29 Jul 2024 10:23:10 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 293286B0095 for ; Mon, 29 Jul 2024 10:23:10 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B789A8041D for ; Mon, 29 Jul 2024 14:23:09 +0000 (UTC) X-FDA: 82393007298.02.96B4B7A Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com [209.85.210.44]) by imf09.hostedemail.com (Postfix) with ESMTP id AD08414003D for ; Mon, 29 Jul 2024 14:23:07 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=iGXfqsg6; spf=pass (imf09.hostedemail.com: domain of gourry@gourry.net designates 209.85.210.44 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722262945; 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=4LXNIPi3GQ0yATRS1VEygNKstEkvEbJ00GT3K3Vkj5U=; b=hBInSHx1k+IgqvamSSXEjrguuUiZjOtDFz+mrs/3FGYVM8dhbNSOzbaP8jyEBjFPqoc9IY Txv4c9bsCHep3Aa5wAbNmKgwQBX8HeohqIwWYetD5v7egHsWHj3QrmR3wVg4KxMWSQ1ztM KcmWET5q2BIYwZZ3OBdtn10IjEV+Mes= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=iGXfqsg6; spf=pass (imf09.hostedemail.com: domain of gourry@gourry.net designates 209.85.210.44 as permitted sender) smtp.mailfrom=gourry@gourry.net; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722262945; a=rsa-sha256; cv=none; b=sS731M34x1a07glI293+7hlzTiVCBTfcAHC4YV6YhhC3NbDd7yyR5y2o606hQKL6Hg52jh pIhl8Exn/Y6Rh94KlGHugvLHaKH5sxpdSxRRJdI5v6d+BfmWbE9IRUO4ohaOgEbJDq83H0 psj69QYDlh1r9f2G1HTpyrKlEcxv1hQ= Received: by mail-ot1-f44.google.com with SMTP id 46e09a7af769-7092fb4317dso2321106a34.0 for ; Mon, 29 Jul 2024 07:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1722262986; x=1722867786; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4LXNIPi3GQ0yATRS1VEygNKstEkvEbJ00GT3K3Vkj5U=; b=iGXfqsg6zDjGZRxb0JUcLup/CGXS9/Jyy3ATevTpLAFdTT90W8/5hizSWM8RfRHz9K ZPVFkTWU7N+rvUbe4EMWcOcITTXapoJF5kKxAjGNy5mOdgNqhJ1TRYoY52M9bxDX2MPJ e8GaV2fhdHwuIN5rTTSWRszSG8KYcGglchkncceKiEbD2l2faS+g1ddc9lv1EDU06Xn6 YB7eiLw75Id6HAIvVxzs1zvVCuK/JOqnUqP+WWVFamu7Z7iewYjQ925Jv/9wAXVzLyiF U1VCik0r4g/b3OE9+Wnh8x63e6UHdJ544cOti7VgfYmBlA4uB8OKJ3MS3pkSbnuuHjEr cqHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722262986; x=1722867786; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4LXNIPi3GQ0yATRS1VEygNKstEkvEbJ00GT3K3Vkj5U=; b=JDuAYXuxiNSeK3mSsdRCBF9f0aOMczz3zuDf5dmknEAtBD/VuFTgDo6wjlM3t6Gt+6 sRUe1JDJb2TGcOtVkzSpprMZpaa3TESoIs0W6oG49wYguSoR8zju4YUCun7PzJX0IKZb mWO2kqiXk3i+hhN9WLgvmJjdClD5o5NzPxC7UGU+fkMasCtOhWK3iiX6dDaUKEVkHhp0 dYMnVDBa0ENxHh+Ccwlv9t3X+9mff4wF/wr6OnrmEjzzhtua3vcOCeJ8GjZN594mKor/ ciGprB2+fg/DtuhIQILwsDmj0UxOhvp8KecCvg2wJ5YA1YzeIKp65HKUkEI8y28LmvxI 2M8A== X-Gm-Message-State: AOJu0YypTaZsjozN/HN+ajli6nonJalMdBGj3kmJ/DEeZCYvlBYmaUSs RnfKGFw1SJ9yopQX6nR1EXCUIDFrwnCYLvQJ8Q9MhGYs2jXTREOmO8P1DXwAnwM= X-Google-Smtp-Source: AGHT+IE4Uc9GN+gfcvZXZsg6oZ02yCqpJXlwIS5AqIAosbUfh5gO+aYR2YPZRWJiMcCTq/IvQzqNNg== X-Received: by 2002:a05:6830:730d:b0:703:6ec7:64e1 with SMTP id 46e09a7af769-70940ba1bd2mr6431952a34.0.1722262986486; Mon, 29 Jul 2024 07:23:06 -0700 (PDT) Received: from PC2K9PVX.TheFacebook.com (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7a1fa4462adsm39342685a.100.2024.07.29.07.23.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jul 2024 07:23:06 -0700 (PDT) Date: Mon, 29 Jul 2024 10:22:52 -0400 From: Gregory Price To: "Huang, Ying" Cc: linux-mm@kvack.org, akpm@linux-foundation.org, dave.jiang@intel.com, Jonathan.Cameron@huawei.com, horenchuang@bytedance.com, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, dan.j.williams@intel.com, lenb@kernel.org Subject: Re: [PATCH] acpi/hmat,mm/memtier: always register hmat adist calculation callback Message-ID: References: <20240726215548.10653-1-gourry@gourry.net> <87ttg91046.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ttg91046.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Stat-Signature: nepqknpyi71gqx8f1n3uciepkp1ntk5s X-Rspam-User: X-Rspamd-Queue-Id: AD08414003D X-Rspamd-Server: rspam02 X-HE-Tag: 1722262987-55146 X-HE-Meta: U2FsdGVkX1+AAfeFP7ypE1A5A6+C3EodclvgOwYmhqaE0dshDgk7UdOd3vu+CW5uivcETiCx7zYGDE5KtIipvAKi6ExeR4U1e2gl8HInQVlfluBGirRaRCoFazgH0zimQUVguQTG0UZ/OD4tzg/EE/5Wr+rllZoOuvfXG2VVdmzqYJO1YCgaFWzR5WzYj9Z2pLloHBmAj+lFv2Yg/O4p1H5Er7AsmfZtimMwt4d8WyWHX2g4JnheVfn3URU2akU161IVdHvzvZz3JCmwIGtvwNGpVqzqwF1doR/PTSNGIZsWZI2JsfU88hwZDxoVY5givGuEPyAZAMc8heOJ/fVebiGRqx5Lyo1aYEaCYZ6BP9gN+MHgoxrP4VlX6DiosY88wmuaoeA4Xux6f5frtp72EdfuMXoFwohQtsC1sRFXMyGC3wc5YaLr85ILChSfP0DjOt4hzMEWKUs0iKhac/XbbcfXt7OxkxmDCAD9ZCltOxnWPqZH9gD2nj5DUGLMDRA3brlyfwnUe+Cu/AuI/nOrHxRyY0SequfnrwEjSLk2SlTLL7Kw6TwydhGnT+dSzqQHfu/mQjBJS66G60f0ByH/axbL3Wgv8vxtjG93XAH35Z9vpbHW258iWtcJeCp600ZSuN+q2g6s4nW24Vexq/pcs72hxTqeqU8kT4QULIQ3KLRrUaZfmOaWqAxtH6Srb+R2MaGHohWkzKQesTnKo29NgalzHyial01RqjP6uZjUir9USKoHxAq8E1O1g+dmW4g4DhD2HkNbLZJWfMCILzQA3oboPXDgwkIwmqaEhThLM+fFVNcQOdv+Zn13Cnq9ODjMzgDTUCmq8LfAg9qO/lPZlCUBiqiF8/Zf5gEQQxTl6RNqT5C+IVcyp5ieccA4J9iGcCqBPsUjTIJZ5hfxAg5/7ABU3mX3N6V0ABw+/042czIlhGya3H0FCmHjguUu2BnX7tDkFAoVqisnUCME9oZ IM2BLuFH qeEe/dHHIFIKJVlYRzG9F3NYjTZ8yNCPMo74LhHEB+VzORZ6+d43511mEsJx5IQB9qE2LSdGWyaTSlTJfGBkqa7Ip2bG95pbxRxJm7q4yMwTitHtW9XDA69QZGg6D5q72e/M2U8vOC/3Ki3KHGHtrVjBVbK6sU+hgDLSi7lufS0GsiDCEIEBgc60dkrTnHIeEexPrU8ed/WYO5fWjlCKiEdCJGOTDK9oQFlVRdMS0tio02J4yA+kwS1UDyq5A/658YUoSq9OUNuZwzwBYEQLoXy135k1q3wvYgcp37nBHB6jFgEHCIUd65IaeFBVS9i2T9f/S X-Bogosity: Ham, tests=bogofilter, spamicity=0.000041, 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 Mon, Jul 29, 2024 at 09:02:33AM +0800, Huang, Ying wrote: > Gregory Price writes: > > > In the event that hmat data is not available for the DRAM tier, > > or if it is invalid (bandwidth or latency is 0), we can still register > > a callback to calculate the abstract distance for non-cpu nodes > > and simply assign it a different tier manually. > > > > In the case where DRAM HMAT values are missing or not sane we > > manually assign adist=(MEMTIER_ADISTANCE_DRAM + MEMTIER_CHUNK_SIZE). > > > > If the HMAT data for the non-cpu tier is invalid (e.g. bw = 0), we > > cannot reasonable determine where to place the tier, so it will default > > to MEMTIER_ADISTANCE_DRAM (which is the existing behavior). > > Why do we need this? Do you have machines with broken HMAT table? Can > you ask the vendor to fix the HMAT table? > It's a little unclear from the ACPI specification whether HMAT is technically optional or not (given that the kernel handles missing HMAT gracefully, it certainly seems optional). In one scenario I have seen incorrect data, and in another scenario I have seen the HMAT omitted entirely. In another scenario I have seen the HMAT-SLLBI omitted while the CDAT is present. In all scenarios the result is the same: all nodes in the same tier. The HMAT is explicitly described as "A hint" in the ACPI spec. ACPI 5.2.28.1 HMAT Overview "The software is expected to use this information as a hint for optimization, or when the system has heterogeneous memory" If something is "a hint", then it should not be used prescriptively. Right now HMAT appears to be used prescriptively, this despite the fact that there was a clear intent to separate CPU-nodes and non-CPU-nodes in the memory-tier code. So this patch simply realizes this intent when the hints are not very reasonable. ~Gregory