From: Prarit Bhargava <prarit@redhat.com>
To: Borislav Petkov <bp@suse.de>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org, Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Len Brown <len.brown@intel.com>, Andi Kleen <ak@linux.intel.com>,
Jiri Olsa <jolsa@redhat.com>, Juergen Gross <jgross@suse.com>
Subject: Re: [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event
Date: Thu, 22 Sep 2016 07:59:08 -0400 [thread overview]
Message-ID: <57E3C78C.5040400@redhat.com> (raw)
In-Reply-To: <20160921140135.i5emid4qno2o6cre@pd.tnic>
On 09/21/2016 10:01 AM, Borislav Petkov wrote:
> On Wed, Sep 21, 2016 at 09:32:47AM -0400, Prarit Bhargava wrote:
>> This is not the right thing to do [1]. The topology directory should exist as
>> long as the thread is present in the system. The thread (and its core) are
>> still physically there, it's just that the thread is not available to the
>> scheduler. The topology of the thread hasn't changed due to it being soft
>> offlined this way.
>
> So far so good.
>
>> turbostat was modified to deal with the missing topology directory, and in tree
>> utility cpupower prints out significantly less information when a thread is
>> offline.
>
> Why does it do that? Why does an offlined core change that info?
>
> Concrete details please.
>
>> ISTR a powertop bug due to hotplug too. This makes these monitoring
>> utilities a problem for users who want only one thread per core.
>
> one thread per core? What does that mean?
System boots with (usually) with 2 threads/core. Some performance users want
one thread per core. Since there is no "noht" option anymore, users use /sys to
disable a thread on each core.
>
>> This now means that
>>
>> echo 0 > /sys/devices/system/cpu/cpu29/online
>>
>> will result in the thread's topology directory staying around until the struct
>> device associated with it is destroyed upon a physical socket hotplug event.
>
> So your 2/2 says that on an offlined CPU, you have
>
> /sys/devices/system/cpu/cpu10/topology/core_id:3
> /sys/devices/system/cpu/cpu10/topology/core_siblings:0000
> /sys/devices/system/cpu/cpu10/topology/core_siblings_list:
> /sys/devices/system/cpu/cpu10/topology/physical_package_id:0
> /sys/devices/system/cpu/cpu10/topology/thread_siblings:0000
> /sys/devices/system/cpu/cpu10/topology/thread_siblings_list:
>
> and this information is bollocks. core_siblings is 0, thread_siblings
> is 0. You can just as well not have them there at all.
core_siblings and thread_siblings are the online thread's sibling cores and
threads that are available to the scheduler, and should be 0 when the thread is
offline. That comes directly from reading the code.
>
> So is this whole jumping around just so that you can have a
> /sys/devices/system/cpu/cpu10/topology directory and so that tools don't
> get confused by it missing?
Yes.
>
> So again, what exactly are those tools accessing and how does the
> offlined cores puzzle them?
>
> A concrete example please:
>
See commit 20102ac5bee3 ("cpupower: cpupower monitor reports uninitialized
values for offline cpus"). That patch papers over the bug of not being able to
find core_id and physical_package_id for an offline thread.
P.
next prev parent reply other threads:[~2016-09-22 11:59 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-21 11:39 [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event Prarit Bhargava
2016-09-21 11:39 ` [PATCH 1/2 v3] drivers/base: Combine topology.c and cpu.c Prarit Bhargava
2016-09-21 11:39 ` [PATCH 2/2 v3] cpu hotplug: add CONFIG_PERMANENT_CPU_TOPOLOGY Prarit Bhargava
2016-09-21 13:04 ` [PATCH 0/2 v3] cpu hotplug: Preserve topology directory after soft remove event Borislav Petkov
2016-09-21 13:32 ` Prarit Bhargava
2016-09-21 14:01 ` Borislav Petkov
2016-09-22 11:59 ` Prarit Bhargava [this message]
2016-09-22 12:10 ` Borislav Petkov
2016-09-26 11:45 ` Prarit Bhargava
2016-09-26 11:57 ` Borislav Petkov
2016-09-27 11:45 ` Prarit Bhargava
2016-09-27 13:49 ` Greg Kroah-Hartman
2016-09-27 15:26 ` Prarit Bhargava
2016-09-28 5:05 ` Borislav Petkov
2016-09-28 6:48 ` Peter Zijlstra
2016-09-28 10:06 ` Prarit Bhargava
2016-09-28 5:02 ` Borislav Petkov
2016-09-26 11:59 ` Peter Zijlstra
2016-09-27 11:47 ` Prarit Bhargava
2016-09-27 11:57 ` Peter Zijlstra
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=57E3C78C.5040400@redhat.com \
--to=prarit@redhat.com \
--cc=ak@linux.intel.com \
--cc=bp@suse.de \
--cc=gregkh@linuxfoundation.org \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=jolsa@redhat.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.