All of lore.kernel.org
 help / color / mirror / Atom feed
From: Prarit Bhargava <prarit@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: "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>,
	"Borislav Petkov" <bp@alien8.de>,
	"Len Brown" <len.brown@intel.com>,
	"Andy Lutomirski" <luto@amacapital.net>,
	"Zhu Guihua" <zhugh.fnst@cn.fujitsu.com>,
	"Denys Vlasenko" <dvlasenk@redhat.com>,
	"\"Jan H. Schönherr\"" <jschoenh@amazon.de>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	"Thomas Renninger" <trenn@suse.de>
Subject: Re: [PATCH 1/2] cpu hotplug, add CONFIG_PERMANENT_CPU_TOPOLOGY and keep topology directory for lifetime of CPU
Date: Mon, 19 Oct 2015 18:26:35 -0400	[thread overview]
Message-ID: <56256E1B.5080404@redhat.com> (raw)
In-Reply-To: <1445267044-29551-2-git-send-email-prarit@redhat.com>



On 10/19/2015 11:04 AM, 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.
> 
> This patch adds CONFIG_PERMANENT_CPU_TOPOLOGY, and is Y by default for
> x86, an N for all other arches.  When enabled the kernel is modified so
> that the topology directory is added to the core cpu sysfs files so that
> the topology directory exists for the lifetime of the CPU.  When
> disabled, the behavior of the current kernel is maintained (that is, the
> topology directory is removed on a down and added on an up).  Adding
> CONFIG_PERMANENT_CPU_TOPOLOGY may require additional architecture so that
> the cpumask data the CPU's topology is not cleared during a CPU down.
> 
> This patch combines drivers/base/topology.c and drivers/base/cpu.c to
> implement CONFIG_PERMANENT_CPU_TOPOLOGY, and leaves all arches except
> x86 with the current behavior.
> 
> Before patch:
> 
> [root@prarit cpu143]# ls
> cache    crash_notes       firmware_node  online     thermal_throttle
> cpufreq  crash_notes_size  microcode      power      topology
> cpuidle  driver            node3          subsystem  uevent
> 
> Down a cpu
> 
> [root@prarit cpu143]# echo 0 > online
> 
> [root@intel-brickland-05 cpu143]# ls
> cpuidle      crash_notes_size  firmware_node  online  subsystem
> crash_notes  driver            node3          power   uevent
> [root@intel-brickland-05 cpu143]# ls -l topology
> ls: cannot access topology: No such file or directory
> 
> After patch:
> 
> [root@prarit cpu143]# ls
> cache    crash_notes       firmware_node  online     thermal_throttle
> cpufreq  crash_notes_size  microcode      power      topology
> cpuidle  driver            node3          subsystem  uevent
> [root@prarit cpu143]# cat topology/*
> 27
> ffff,c0000000,000000ff,ffc00000,00000000
> 54-71,126-143
> 3
> 8000,00000000,00000080,00000000,00000000
> 71,143
> 
> Down a cpu
> 
> [root@prarit cpu143]# echo 0 > online
> [root@intel-brickland-05 cpu143]# ls
> cpuidle      crash_notes_size  firmware_node  online  subsystem  uevent
> crash_notes  driver	       node3	      power   topology
> [root@prarit cpu143]# cat topology/*
> 27
> ffff,c0000000,000000ff,ffc00000,00000000
> 54-71,126-143
> 3
> 8000,00000000,00000080,00000000,00000000
> 71,143
> 
> I did some light testing with and without BOOTPARAM_HOTPLUG_CPU0 enabled,
> and up'd and down'd CPUs in sequence, randomly, by thread group, by
> socket group and didn't see any issues.
> 
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Ingo Molnar <mingo@redhat.com>
> Cc: "H. Peter Anvin" <hpa@zytor.com>
> Cc: x86@kernel.org
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Borislav Petkov <bp@alien8.de>
> Cc: Len Brown <len.brown@intel.com>
> Cc: Andy Lutomirski <luto@amacapital.net>
> Cc: Zhu Guihua <zhugh.fnst@cn.fujitsu.com>
> Cc: Denys Vlasenko <dvlasenk@redhat.com>
> Cc: "Jan H. Schönherr" <jschoenh@amazon.de>
> Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
> Cc: Prarit Bhargava <prarit@redhat.com>
> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> Cc: Thomas Renninger <trenn@suse.de>
> Signed-off-by: Prarit Bhargava <prarit@redhat.com>
> ---
>  arch/x86/kernel/smpboot.c |   28 --------
>  drivers/base/Kconfig      |   13 ++++
>  drivers/base/Makefile     |    2 +-
>  drivers/base/cpu.c        |  135 +++++++++++++++++++++++++++++++++++++++
>  drivers/base/topology.c   |  155 ---------------------------------------------
>  5 files changed, 149 insertions(+), 184 deletions(-)
>  delete mode 100644 drivers/base/topology.c
> 
> diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
> index e0c198e..19082c7 100644
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1322,32 +1322,6 @@ __init void prefill_possible_map(void)
>  
>  #ifdef CONFIG_HOTPLUG_CPU
>  
> -static void remove_siblinginfo(int cpu)
> -{
> -	int sibling;
> -	struct cpuinfo_x86 *c = &cpu_data(cpu);
> -
> -	for_each_cpu(sibling, topology_core_cpumask(cpu)) {
> -		cpumask_clear_cpu(cpu, topology_core_cpumask(sibling));
> -		/*/
> -		 * last thread sibling in this cpu core going down
> -		 */
> -		if (cpumask_weight(topology_sibling_cpumask(cpu)) == 1)
> -			cpu_data(sibling).booted_cores--;
> -	}
> -
> -	for_each_cpu(sibling, topology_sibling_cpumask(cpu))
> -		cpumask_clear_cpu(cpu, topology_sibling_cpumask(sibling));
> -	for_each_cpu(sibling, cpu_llc_shared_mask(cpu))
> -		cpumask_clear_cpu(cpu, cpu_llc_shared_mask(sibling));
> -	cpumask_clear(cpu_llc_shared_mask(cpu));
> -	cpumask_clear(topology_sibling_cpumask(cpu));
> -	cpumask_clear(topology_core_cpumask(cpu));


It was just pointed out to me that the these masks tend to be used in
the kernel as "sibling & online mask", and "core & online_mask".  The other
values are indeed static and are safe to use.

I'll "self-nak" this and come up with a slightly better patchset.

P.

  parent reply	other threads:[~2015-10-19 22:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-19 15:04 [PATCH 0/2] Add CONFIG_PERMANENT_CPU_TOPOLOGY Prarit Bhargava
2015-10-19 15:04 ` [PATCH 1/2] cpu hotplug, add CONFIG_PERMANENT_CPU_TOPOLOGY and keep topology directory for lifetime of CPU Prarit Bhargava
2015-10-19 15:48   ` kbuild test robot
2015-10-19 22:26   ` Prarit Bhargava [this message]
2015-10-19 15:04 ` [PATCH 2/2] base, cpu, remove hotplugable_cpu_attr_groups Prarit Bhargava

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=56256E1B.5080404@redhat.com \
    --to=prarit@redhat.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hpa@zytor.com \
    --cc=jschoenh@amazon.de \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=mingo@redhat.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=trenn@suse.de \
    --cc=x86@kernel.org \
    --cc=zhugh.fnst@cn.fujitsu.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 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.