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 9ADABC3DA7F for ; Wed, 31 Jul 2024 06:38:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A501E6B0082; Wed, 31 Jul 2024 02:38:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A01136B0083; Wed, 31 Jul 2024 02:38:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C8136B0085; Wed, 31 Jul 2024 02:38:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 6ECD96B0082 for ; Wed, 31 Jul 2024 02:38:37 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 1598AA2343 for ; Wed, 31 Jul 2024 06:38:37 +0000 (UTC) X-FDA: 82399094274.27.D16997A Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf23.hostedemail.com (Postfix) with ESMTP id 39573140016 for ; Wed, 31 Jul 2024 06:38:35 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=ro0GyKaW; dmarc=none; spf=pass (imf23.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.170 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722407853; 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=iah49N2YpJoLvB1OkYWrt6kJLlPNBil8tRCIq4onM8c=; b=0eJ26Id/OEZPUjBo7SXLKU+HHeYZIpj0YKcNvrcoXGfFe9IWAkwSmLKjKWiZNKGbb0trLK /z80+41AiRoZpar++DIa/OEyXyjmyQTa5z2WhV8D3d2r00BX4YPBwt7M+RpD9pnJ73UQ9Z e07b+aNtw4MAT4QmoekYO3ww2aWZpyw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722407853; a=rsa-sha256; cv=none; b=o1RkG2OhFSiAa8VCT3pCWUUdWvLR9O3Jw7tFB3M1q628clkWXuVf6O+pdUO8eOHif4u+iF ocOMCcgpir3mR8bSZ4MeYPe+61SMy+rZjkb0njMD1N+M7F0o9IUg40RcAkjxPZP0+kOxyG My94YY3FnZf+me9jWs+EwFPmbsRrG3I= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=ro0GyKaW; dmarc=none; spf=pass (imf23.hostedemail.com: domain of gourry@gourry.net designates 209.85.222.170 as permitted sender) smtp.mailfrom=gourry@gourry.net Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-7a1d5f6c56fso347936185a.0 for ; Tue, 30 Jul 2024 23:38:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1722407914; x=1723012714; 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=iah49N2YpJoLvB1OkYWrt6kJLlPNBil8tRCIq4onM8c=; b=ro0GyKaWH8RJJmwV46vMwfciWhUq06gtMe1d2Yv646NZWjzw5wsD9KnFUf0AmiYyXU j5x5NIYqq4/BufbGEHxd+ZH65OigCnESzDM9dQOjkyx4p4dsQKKuhlGv7hFU7kG6P2E2 v4ulRsJ0QbNYlrrdTaDfDfLwKTPIJMqQa8WV59n/YpIlmGBH5su0ZH6uTnQC3o+vII/O vuSKOtHuZHLezC0jHzlnYPqBmZRJwcCW7vGDC6lK4yo/MRmzlb4b/F+9k5dupQiNUHHx RG8qqYGzDsEhy0Wx4rUjCSz+oNdVkW/GUY0vKUn6dW8QO6FCNlLTcbpbxI+KeMyzjivV hB3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722407914; x=1723012714; 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=iah49N2YpJoLvB1OkYWrt6kJLlPNBil8tRCIq4onM8c=; b=BVRjG4Y8qhIuwczDPdlU8o6d2vZrwt4FKtZb3Hg0MSOBikv5x/Xmrd2PSMCWspDSc5 u8WEf7RZzR5REvNgQy3i4ry6xipKU/yg4a3kdEDIFykkJRleXNzuolndA6mnse4HhLhl i/BU0pGXhpxVQve2TCgL6k4HsQnIKCoZx2qrr2QstdNZ2KmRkz4POPxsFeJT76ZIzQmT IAy5r/5NidA9iCedlaahV++WIrXGX00iH1ARdS7M9fLtyNXeLr4ttaXSGZdV3yOQ62e9 juSMmjhfYgvkCZ8WBxjLNaI3x8e4t7m9KES499ViAPp+VgZY1eL2Oz8nsFDgpKR3LjVt zQiQ== X-Gm-Message-State: AOJu0YyYWw27jdVoIWSd5ePSpzmW2kMd3DlKErxAQDxec5dF9fWNCAIo EbpmvHfxqUZkvVZ3f707KL4cgCU7zcOzLF7EvdWKZeNhejS5iRSW3p/iyOT05xg= X-Google-Smtp-Source: AGHT+IFIqBKAGa+6ov0v12YBmIbiEzdWKjZhz5dVIHwK9CTB6/yjtbXp/O+lkF8ZkzynVFyaT3LoKg== X-Received: by 2002:a05:620a:400f:b0:79f:329:6790 with SMTP id af79cd13be357-7a1e52f6aa3mr1659029185a.66.1722407914197; Tue, 30 Jul 2024 23:38:34 -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-7a1d7395188sm713919985a.3.2024.07.30.23.38.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jul 2024 23:38:33 -0700 (PDT) Date: Tue, 30 Jul 2024 15:58:10 -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, "Aneesh Kumar K.V" 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> <877cd3u1go.fsf@yhuang6-desk2.ccr.corp.intel.com> <87cymupd7r.fsf@yhuang6-desk2.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87cymupd7r.fsf@yhuang6-desk2.ccr.corp.intel.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 39573140016 X-Stat-Signature: nts4xz3hskebe7e7haj6dt767oakeh7s X-Rspam-User: X-HE-Tag: 1722407915-659923 X-HE-Meta: U2FsdGVkX18uKRL/qlLnE+fLd2nWGttC6XGQdsy93NYqTK5r5FoN0vWz+B3GsCX0Bv8jlwpTJhqIagZPRlvliZo+xXTkYDdoWfDQjvNv53ZcS74xv5iToeHN5FuxsW1t8maxkf4hRSEPRIdHF8MaWo0lD2bDyPi8Ob93pFLJsNQOA78hmvfcn+Hy5guDX1No2YbHP31LuvHs+EWsV/76wIJd2aT1XK2XFdJhgZz/Qhg/XOqdSLmugkJhqwOgQb2WlCpaPNVjHtsblpFXjLbG6mOR4ZIGrwiDNw6z2QrGrZLW0KormtI6JCZeLw4JpPIG538mZBoqRpLdpHGPjJlWM83t6N/NtVZk0uVEAPhzv7qXOAX20tXqFpGB0XN7Eo+iGr/v35nRe5/CZ5s20lnc7j3h8EgMX0pWBjKH1wf7XZ5fswIVU/WE9HjcDKLazrpykWmPUtTZRPRdEFBfmXgRtIhd5YUEvYk20iDFBko0B8UW7N5KRdOXokfJKBXopzXTUHAktxnWZDL4e++NrhhVT/4fonNjBelMKi5pIm0ysmo1J1M9MEpt44rKNCpQ4hA3dH/PYGG1Zj73+ekQ1ApSkuFIItBmCc6roEOgDpUPIMin5UD/u5OPa76yyCei4+34cndHjDkyp5AhITXokrAUhrr9lOeIQc2mHG8x2zU5MuFBX9sO2IU7k06WISnlcZqmMZNNVYgFtx4mBajfkkCti68lPfSVCzeqJxIEOC+eEc64FMtAzmM1zSjU3vZsnID2uKY4R9qREf0ur4B5ae8m1znX/duuplu6uE0ecxvMZGCQ2h/JvFtyjGGU21rTeAMaSoQCMHzZabdEVTGOM+9qFi4prU63E8vgy6aoPgxlzuVMLqLIDK5S/GLuUPDpz9P6kj3nsnLUzTQoSnbvx4LpeUql9Yc+alHaUeLe5SnhNneOSrIiGsrZJKiXUEbnQ9YqkVEtG3dgM9x49nNxWsR LxGjSivm DkbLcw+0XCgdzy5vgAz94lFeoyy1po7SNQ3+c7ozDoh9zsR/7WxpzIOuSroS6AU0Ad947Mj9GcI2w++t/xXjUWgiZ0tEDA9N3L/WEEyD6C5zkH5TroqMNCHW48MV9RmZUgxLbXW7UkUCSafzHhxRNg9vHq5gXmyP88XqRCXyfVdjWvT0mcHRhqwCCtUYdhjiVCxU+4t3e28u7CEH1f6zNsg9nHLGFo+aNqYCJHGDc2e64AkeIC7xJmymG5Y8uLPBlpQse2V3Fj6Hf4bmpaFAStpf3rGmNXAxe0OQVsfUyTDNze1Z44RUtufzuMyYmEa/jWXxR 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, Jul 31, 2024 at 09:22:32AM +0800, Huang, Ying wrote: > Gregory Price writes: > > > This presumes driver configured devices, which is not always the case. > > > > kmem.c will set MEMTIER_DEFAULT_DAX_ADISTANCE > > > > but if BIOS/EFI has set up the node instead, you get the default of > > MEMTIER_ADISTANCE_DRAM if HMAT is not present or otherwise not sane. > > "efi_fake_mem=" kernel parameter can be used to add "EFI_MEMORY_SP" flag > to the memory range, so that kmem.c can manage it. > In this case, the system is configured explicitly so that kmem does not manage it. In fact, some systems still cannot be managed with EFI_MEMORY_SP due to hpa!=spa issues that the driver cannot manage. > > Not everyone is going to have the ability to get a platform vendor to > > fix a BIOS bug, and I've seen this in production. > > So, some vendor build a machine with broken/missing HMAT/CDAT and wants > users to use CXL memory devices in it? Have the vendor tested whether > CXL memory devices work? > As I mentioned, the broken aspect is being fixed, however there are existing production hardware which do not have HMAT entries. > > But the first step here would be creating two modes. HMAT-is-sane and > > CPU/Non-CPU seems reasonable to me but open to opinions. > > IMHO, we should reduce user configurable knobs unless we can prove it > is really necessary. > That's fair and valid. But I think a feature that worked in 5.x should work in 6.x, and right now the change in node placement breaks hardware that worked with 5.x which happened to have broken or missing HMAT. ~Gregory