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: Wed, 21 Sep 2016 09:32:47 -0400 [thread overview]
Message-ID: <57E28BFF.8060107@redhat.com> (raw)
In-Reply-To: <20160921130428.2e7bprll64vs6h2r@pd.tnic>
On 09/21/2016 09:04 AM, Borislav Petkov wrote:
> On Wed, Sep 21, 2016 at 07:39:31AM -0400, Prarit Bhargava wrote:
>> The information in /sys/devices/system/cpu/cpuX/topology
>> directory is useful for userspace monitoring applications and in-tree
>> utilities like cpupower & turbostat.
>>
>> When down'ing a CPU the /sys/devices/system/cpu/cpuX/topology directory is
>> removed during the CPU_DEAD hotplug callback in the kernel. The problem
>> with this model is that the CPU has not been physically removed and the
>> data in the topology directory is still valid. IOW, the cpu is still
>> present but the kernel has removed the topology directory making it
>> very difficult to determine exactly where the cpu is located.
>
> So I'm afraid I still don't understand what the problem here is.
>
> And the commit message of 2/2 doesn't make it any clearer. Can you
> please give a concrete example what the problem is and what you're
> trying to achieve.
Sorry, I'll try again....
Right now, if you removed thread 29 from your system you would do:
echo 0 > /sys/devices/system/cpu/cpu29/online
>From the userspace side, this results in the removing of the
/sys/devices/system/cpu/cpu29/topology
directory.
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.
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. ISTR a powertop bug due to hotplug too. This makes these monitoring
utilities a problem for users who want only one thread per core.
The patchset does two things. The first patch unifies the topology.c and cpu.c
code. The second patch introduces a config option to change the lifetime of the
topology directory to exist as long as the thread's device struct exists in the
device subsystem.
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.
This patchset will result in cleanups to turbostat, and make fixes to cpupower
*much* easier to deal with.
[1] I cannot say with any certainty that other arches do or do not require this
change. That is the only reason the change is restricted to x86 right now.
P.
>
> Thanks.
>
next prev parent reply other threads:[~2016-09-21 13:39 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 [this message]
2016-09-21 14:01 ` Borislav Petkov
2016-09-22 11:59 ` Prarit Bhargava
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=57E28BFF.8060107@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).