From nobody Tue Nov 26 20:00:13 2024 Received: from mail-vs1-f50.google.com (mail-vs1-f50.google.com [209.85.217.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 78E78216A2C for ; Wed, 16 Oct 2024 19:25:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.217.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729106721; cv=none; b=kYzzHYKKNnaQ7dRj4SPPJmrYqPQHsO6yXctKkEcHlMWUf+2ffXm7hGVhwov0buRIBhZRLf48S9BR773h4VJ2XXFT+uZtjF98qA8vGScedgMveDlCt/ksaBHU/czkZeJZ/KxgGbWViQd5ME5WvBj/RZn1hcmKfdf0mrRToR8RHe0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1729106721; c=relaxed/simple; bh=5d0MbCIw8EE2ZSOCUaim9gDCiiqCphBCQxQbxbqbXHY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=uKx9wb8sKEspwHBDM5WhXfr8Pa3qRGBtcDNN+MqsvJLYRVBjeKIZM7Lgv8g0BhBlUvzNUXSkcvIePndtewVxCiQzlldVsAwNMUhy4R8zSEhSccGvjU6A65dz8bE9tFXVfRmVosWE4CK/38yAbN05dZItEZjPrO9f4Qv4PxR+FF8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=mPKEV0fu; arc=none smtp.client-ip=209.85.217.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="mPKEV0fu" Received: by mail-vs1-f50.google.com with SMTP id ada2fe7eead31-4a470d330a5so46383137.3 for ; Wed, 16 Oct 2024 12:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1729106718; x=1729711518; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=HrmbhAeCdsnN6DuwhCdjgoaV0xg9bEsX7zAMN4X3gqU=; b=mPKEV0fuQxrYnrKL/HSLmS3sJ2k+KOxcrykrrDwRBvQur6XljwNuA7m1D4FsWjTxkT p3aDYUXaNUHuXhVeWVHYnQwVBjkuxjCSW8eYi+Xs1JuTt2zALQeTx4PvekEuFcd+52pf hEQqA+nguO8ErvQ2Tiovn9GDWCym76ilBr1hkCUuwyZyh/YzDpZ3fcsxzXnlDgn7Sm4g pPtsnAu0Li8ddrtlMvsGC2Imk/a/KK3DirPg7B2wQl2qaLOmm20WdtWGXS0S6XsR1DNn hQua5qAsMyimY4E1YAsCQzSkpnjmTCSWbuT0O99UtX8noO39lLUhI3kytPGPTR/U8B+b VJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729106718; x=1729711518; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HrmbhAeCdsnN6DuwhCdjgoaV0xg9bEsX7zAMN4X3gqU=; b=hZbzQAXgetl/R+4V/nzsn3oMtG7VPO0exB03wOksNCwHpY0d1rE03/SLfQMAF3G/xw XFA9oOPONYQBeI46hh0pZxPgqJySmOdcAyxaTu1yZHeHyN5hqZJ0OaDehhEIGJuiuf8R wkKrnbLLuUBSxGJv0iQ1Bix1QiHKwHv8x6IkFbadP82Ksw1qf/kPUGNUskNNMU2GvYEJ 7rlHK+1axghorQDmody9hZovuOOi5bKIXVPLKm2/qlQjei/tHfPcVecFtws41IZADtHy 7su+BOU6yLk7P1AOl2jbXKPB0/ybaJCuyu9IhnpJemliVAPgymXv8bpb0EX3YvRqFSp1 SkKw== X-Forwarded-Encrypted: i=1; AJvYcCV+LP19CHGB2lUE5MhyBgEv9h6pp4j1S2JeGVnbNYqzHN4QyiF38ewyZf10vJ37Gc9sWb+dlt8v+bwbRSE=@vger.kernel.org X-Gm-Message-State: AOJu0YxEIKTpNrplh9/BCpt9T+Xmw8Rjgv/n6Brh/rH6lgu6UDNQpUqX mz83LL53+M9ESyYk2vP3KTGToD6z8J3j27mFfEt0I4wZPAw1Tr+HBo4S02bYWEk= X-Google-Smtp-Source: AGHT+IFClvWp9HyykvU9mzj84/mtwGebanX8vIYbiVaXquh13pEcA6fQ2yrNp4hn0Qu9cQWW9s3xDg== X-Received: by 2002:a05:6102:d92:b0:4a5:ba70:1c6e with SMTP id ada2fe7eead31-4a5ba702ba3mr3418941137.29.1729106718285; Wed, 16 Oct 2024 12:25:18 -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 d75a77b69052e-4607b38ce69sm20271651cf.90.2024.10.16.12.25.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Oct 2024 12:25:17 -0700 (PDT) From: Gregory Price To: x86@kernel.org, linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org, linux-mm@kvack.org Cc: dan.j.williams@intel.com, ira.weiny@intel.com, david@redhat.com, dave.hansen@linux.intel.com, luto@kernel.org, peterz@infradead.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, hpa@zytor.com, rafael@kernel.org, lenb@kernel.org, rppt@kernel.org, akpm@linux-foundation.org, alison.schofield@intel.com, Jonathan.Cameron@huawei.com, rrichter@amd.com, ytcoode@gmail.com, haibo1.xu@intel.com, dave.jiang@intel.com Subject: [PATCH v2 3/3] acpi,srat: reduce memory block size if CFMWS has a smaller alignment Date: Wed, 16 Oct 2024 15:24:45 -0400 Message-ID: <20241016192445.3118-4-gourry@gourry.net> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20241016192445.3118-1-gourry@gourry.net> References: <20241016192445.3118-1-gourry@gourry.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The CXL Fixed Memory Window allows for memory aligned down to the size of 256MB. However, by default on x86, memory blocks increase in size as total System RAM capacity increases. On x86, this caps out at 2G when 64GB of System RAM is reached. When the CFMWS regions are not aligned to memory block size, this results in lost capacity on either side of the alignment. Parse all CFMWS to detect the largest common denomenator among all regions, and advise memblock to reduce the block size accordingly. Suggested-by: Dan Williams Signed-off-by: Gregory Price --- drivers/acpi/numa/srat.c | 42 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 42 insertions(+) diff --git a/drivers/acpi/numa/srat.c b/drivers/acpi/numa/srat.c index 44f91f2c6c5d..5fc03a99570e 100644 --- a/drivers/acpi/numa/srat.c +++ b/drivers/acpi/numa/srat.c @@ -14,6 +14,7 @@ #include #include #include +#include #include #include #include @@ -333,6 +334,35 @@ acpi_parse_memory_affinity(union acpi_subtable_headers= *header, return 0; } =20 +/* + * CXL allows CFMW to be aligned along 256MB boundaries, but large memory + * systems default to larger alignments (2GB on x86). Misalignments can + * cause some capacity to become unreachable. Calculate the largest suppor= ted + * alignment for all CFMW to maximize the amount of mappable capacity. + */ +static int __init acpi_align_cfmws(union acpi_subtable_headers *header, + void *arg, const unsigned long table_end) +{ + struct acpi_cedt_cfmws *cfmws =3D (struct acpi_cedt_cfmws *)header; + u64 start =3D cfmws->base_hpa; + u64 size =3D cfmws->window_size; + unsigned long *fin_bz =3D arg; + unsigned long bz; + + for (bz =3D SZ_64T; bz >=3D SZ_256M; bz >>=3D 1) { + if (IS_ALIGNED(start, bz) && IS_ALIGNED(size, bz)) + break; + } + + /* Only adjust downward, we never want to increase block size */ + if (bz < *fin_bz && bz >=3D SZ_256M) + *fin_bz =3D bz; + else if (bz < SZ_256M) + pr_err("CFMWS: [BIOS BUG] base/size alignment violates spec\n"); + + return 0; +} + static int __init acpi_parse_cfmws(union acpi_subtable_headers *header, void *arg, const unsigned long table_end) { @@ -501,6 +531,7 @@ acpi_table_parse_srat(enum acpi_srat_type id, int __init acpi_numa_init(void) { int i, fake_pxm, cnt =3D 0; + unsigned long bz =3D SZ_64T; =20 if (acpi_disabled) return -EINVAL; @@ -552,6 +583,17 @@ int __init acpi_numa_init(void) } last_real_pxm =3D fake_pxm; fake_pxm++; + + /* Calculate and set largest supported memory block size alignment */ + acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_align_cfmws, &bz); + if (bz >=3D SZ_256M) { + if (memblock_advise_size_order(ffs(bz)-1) < 0) + pr_warn("CFMWS: memblock size advise failed\n"); + else + pr_info("CFMWS: memblock advised size(%ld)\n", bz); + } + + /* Then parse and fill the numa nodes with the described memory */ acpi_table_parse_cedt(ACPI_CEDT_TYPE_CFMWS, acpi_parse_cfmws, &fake_pxm); =20 --=20 2.43.0