From: Brice Goglin <brice.goglin@gmail.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
Jeffrey Hugo <jhugo@codeaurora.org>,
Jeremy Linton <jeremy.linton@arm.com>,
rjw@rjwysocki.net, linux-acpi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, vkilari@codeaurora.org
Subject: Re: [PATCH] ACPI/PPTT: Handle architecturally unknown cache types
Date: Thu, 13 Sep 2018 06:51:38 +0100 [thread overview]
Message-ID: <4f253bf4-ef2d-849f-b793-9b0530e72aab@gmail.com> (raw)
In-Reply-To: <f8dc2958-a7c7-a633-3a06-97fed7c3510b@arm.com>
Le 12/09/2018 à 11:49, Sudeep Holla a écrit :
>
>> Yes. Without this change, we hit the lscpu error in the commit message,
>> and get zero output about the system. We don't even get information
>> about the caches which are architecturally specified or how many cpus
>> are present. With this change, we get what we expect out of lscpu (and
>> also lstopo) including the cache(s) which are not architecturally
>> specified.
>>
> lscpu and lstopo are so broken. They just assume everything on CPU0.
> If you hotplug them out, you start seeing issues. So reading and file
> that doesn't exist and then bail out on other essential info though they
> are present, hmmm ...
Can you elaborate?
I am not sure cpu0 is supposed to be offlineable on Linux. There's no
"online" file in /sys/devices/system/cpu/cpu0. That's why former lstopo
doesn't like CPU0 being hotplugged out. We are actually making that case
work for another non-standard corner case. But offlining "cpu0" this is
considered "normal", somebody must add that missing "online" sysfs
attribute for "cpu0" (change
https://elixir.bootlin.com/linux/latest/source/drivers/base/cpu.c#L375).
By the way, did anybody actually see an error with lstopo when there's
no "type" attribute for L3? I can't reproduce any issue, we just skip
that specific cache entirely, but everything else appears. If you guys
want to make that "no_cache" cache appear, I'll make it a Unified cache
unless you tell me what to show :)
Brice
next prev parent reply other threads:[~2018-09-13 5:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-11 19:32 [PATCH] ACPI/PPTT: Handle architecturally unknown cache types Jeffrey Hugo
2018-09-11 20:16 ` Jeremy Linton
2018-09-11 20:38 ` Jeffrey Hugo
2018-09-11 21:25 ` Jeremy Linton
2018-09-12 14:41 ` Jeffrey Hugo
2018-09-12 15:27 ` Sudeep Holla
2018-09-12 15:38 ` Sudeep Holla
2018-09-12 15:57 ` Jeffrey Hugo
2018-09-12 16:15 ` Sudeep Holla
2018-09-12 16:25 ` Jeffrey Hugo
2018-09-12 15:39 ` Jeremy Linton
2018-09-12 16:06 ` Jeffrey Hugo
2018-09-12 10:49 ` Sudeep Holla
2018-09-12 14:48 ` Jeffrey Hugo
2018-09-12 15:32 ` Sudeep Holla
2018-09-13 5:51 ` Brice Goglin [this message]
2018-09-13 9:39 ` James Morse
2018-09-13 10:35 ` Sudeep Holla
2018-09-13 11:53 ` Brice Goglin
2018-09-13 15:10 ` Jeffrey Hugo
2018-09-13 15:16 ` Sudeep Holla
2018-09-12 10:37 ` Sudeep Holla
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=4f253bf4-ef2d-849f-b793-9b0530e72aab@gmail.com \
--to=brice.goglin@gmail.com \
--cc=jeremy.linton@arm.com \
--cc=jhugo@codeaurora.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=sudeep.holla@arm.com \
--cc=vkilari@codeaurora.org \
/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