mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
To: x86@kernel.org
Cc: Andreas Herrmann <aherrmann@suse.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Chen Yu <yu.c.chen@intel.com>, Len Brown <len.brown@intel.com>,
	Radu Rendec <rrendec@redhat.com>,
	Pierre Gondois <Pierre.Gondois@arm.com>, Pu Wen <puwen@hygon.cn>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Sudeep Holla <sudeep.holla@arm.com>,
	Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>,
	Will Deacon <will@kernel.org>, Zhang Rui <rui.zhang@intel.com>,
	Nikolay Borisov <nik.borisov@suse.com>,
	Huang Ying <ying.huang@intel.com>,
	Ricardo Neri <ricardo.neri@intel.com>,
	linux-kernel@vger.kernel.org
Subject: [PATCH v5 0/4] x86/cacheinfo: Set the number of leaves per CPU
Date: Mon, 26 Aug 2024 22:16:31 -0700	[thread overview]
Message-ID: <20240827051635.9114-1-ricardo.neri-calderon@linux.intel.com> (raw)

Hi,

The interface /sys/devices/system/cpu/cpuX/cache is broken (not populated)
if CPUs have different numbers of subleaves in CPUID 4. This is the case
of Intel Meteor Lake, which now is out in the world.

This is v5 of a patchset to fix the cache sysfs interface by setting the
number of cache leaves independently for each CPU.

v1, v2, v3, and v4 can be found here[1], here[2], here[3], and here[4].

All the tests described in [5] passed.

Changes since v4:
  * Combined two condition checks into one line. (Sudeep)
  * Added one more Reviewed-by tag from Sudeep. Thanks!

Changes since v3:
  * Fixed another NULL-pointer dereference when checking the validity of
    the last-level cache info.
  * Added the Reviewed-by tags from Radu and Sudeep. Thanks!
  * Rebased on v6.7-rc5.

Changes since v2:
  * This version uncovered a NULL-pointer dereference in recent changes to
    cacheinfo[6]. This dereference is observed when the system does not
    configure cacheinfo early during boot nor makes corrections later
    during CPU hotplug; as is the case in x86. Patch 1 fixes this issue.

Changes since v1:
  * Dave Hansen suggested to use the existing per-CPU ci_cpu_cacheinfo
    variable. Now the global variable num_cache_leaves became useless.
  * While here, I noticed that init_cache_level() also became useless:
    x86 does not need ci_cpu_cacheinfo::num_levels.

Thanks and BR,
Ricardo

[1]. https://lore.kernel.org/lkml/20230314231658.30169-1-ricardo.neri-calderon@linux.intel.com/
[2]. https://lore.kernel.org/all/20230424001956.21434-1-ricardo.neri-calderon@linux.intel.com/
[3]. https://lore.kernel.org/lkml/20230805012421.7002-1-ricardo.neri-calderon@linux.intel.com/
[4]. https://lore.kernel.org/all/20231212222519.12834-1-ricardo.neri-calderon@linux.intel.com/
[5]. https://lore.kernel.org/lkml/20230912032350.GA17008@ranerica-svr.sc.intel.com/
[6]. https://lore.kernel.org/all/20230412185759.755408-1-rrendec@redhat.com/

Ricardo Neri (4):
  cacheinfo: Check for null last-level cache info
  cacheinfo: Allocate memory for memory if not done from the primary CPU
  x86/cacheinfo: Delete global num_cache_leaves
  x86/cacheinfo: Clean out init_cache_level()

 arch/x86/kernel/cpu/cacheinfo.c | 49 +++++++++++++++++----------------
 drivers/base/cacheinfo.c        |  8 ++++--
 2 files changed, 32 insertions(+), 25 deletions(-)

-- 
2.34.1


             reply	other threads:[~2024-08-27  5:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-27  5:16 Ricardo Neri [this message]
2024-08-27  5:16 ` [PATCH v5 1/4] cacheinfo: Check for null last-level cache info Ricardo Neri
2024-09-01 18:07   ` Andreas Herrmann
2024-08-27  5:16 ` [PATCH v5 2/4] cacheinfo: Allocate memory for memory if not done from the primary CPU Ricardo Neri
2024-08-28 13:16   ` Nikolay Borisov
2024-08-28 13:57     ` Sudeep Holla
2024-08-29  4:37       ` Ricardo Neri
2024-09-01 18:08   ` Andreas Herrmann
2024-08-27  5:16 ` [PATCH v5 3/4] x86/cacheinfo: Delete global num_cache_leaves Ricardo Neri
2024-08-28 12:57   ` Nikolay Borisov
2024-08-29  4:33     ` Ricardo Neri
2024-09-01 18:08   ` Andreas Herrmann
2024-08-27  5:16 ` [PATCH v5 4/4] x86/cacheinfo: Clean out init_cache_level() Ricardo Neri
2024-08-28 14:01   ` Nikolay Borisov
2024-08-29  4:38     ` Ricardo Neri
2024-09-01 18:09   ` Andreas Herrmann
2024-09-02  7:41     ` Andreas Herrmann
2024-09-04  7:30       ` Ricardo Neri

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240827051635.9114-1-ricardo.neri-calderon@linux.intel.com \
    --to=ricardo.neri-calderon@linux.intel.com \
    --cc=Pierre.Gondois@arm.com \
    --cc=aherrmann@suse.com \
    --cc=catalin.marinas@arm.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nik.borisov@suse.com \
    --cc=puwen@hygon.cn \
    --cc=rafael.j.wysocki@intel.com \
    --cc=ricardo.neri@intel.com \
    --cc=rrendec@redhat.com \
    --cc=rui.zhang@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    --cc=sudeep.holla@arm.com \
    --cc=will@kernel.org \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    --cc=yu.c.chen@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®