Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1365409 > unrolled thread

Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit  accumulated power Borislav Petkov <bp@alien8.de> - 2016-03-28 11:40 +0200
    Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit  accumulated power Peter Zijlstra <peterz@infradead.org> - 2016-03-29 09:40 +0200
      Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit  accumulated power Borislav Petkov <bp@alien8.de> - 2016-03-29 10:00 +0200

#1365409 — Re: [PATCH v5 2/6] hwmon: (fam15h_power) Add compute unit accumulated power

On Mon, Mar 28, 2016 at 01:32:12PM +0800, Huang Rui wrote:
> This patch adds a member in fam15h_power_data which specifies the
> compute unit accumulated power. It adds do_read_registers_on_cu to do
> all the read to all MSRs and run it on one of the online cores on each
> compute unit with smp_call_function_many(). This behavior can decrease
> IPI numbers.
> 
> Suggested-by: Borislav Petkov <bp@alien8.de>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  drivers/hwmon/fam15h_power.c | 65 +++++++++++++++++++++++++++++++++++++++++++-
>  1 file changed, 64 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 4f695d8..ccbc944 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -25,6 +25,8 @@
>  #include <linux/module.h>
>  #include <linux/pci.h>
>  #include <linux/bitops.h>
> +#include <linux/cpu.h>
> +#include <linux/cpumask.h>
>  #include <asm/processor.h>
>  #include <asm/msr.h>
>  
> @@ -44,7 +46,9 @@ MODULE_LICENSE("GPL");
>  
>  #define FAM15H_MIN_NUM_ATTRS		2
>  #define FAM15H_NUM_GROUPS		2
> +#define MAX_CUS				8
>  
> +#define MSR_F15H_CU_PWR_ACCUMULATOR	0xc001007a
>  #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
>  
>  #define PCI_DEVICE_ID_AMD_15H_M70H_NB_F4 0x15b4
> @@ -59,6 +63,8 @@ struct fam15h_power_data {
>  	struct attribute_group group;
>  	/* maximum accumulated power of a compute unit */
>  	u64 max_cu_acc_power;
> +	/* accumulated power of the compute units */
> +	u64 cu_acc_power[MAX_CUS];
>  };
>  
>  static ssize_t show_power(struct device *dev,
> @@ -125,6 +131,63 @@ static ssize_t show_power_crit(struct device *dev,
>  }
>  static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>  
> +static void do_read_registers_on_cu(void *_data)
> +{
> +	struct fam15h_power_data *data = _data;
> +	int cpu, cu;
> +
> +	cpu = smp_processor_id();
> +
> +	/*
> +	 * With the new x86 topology modelling, cpu core id actually
> +	 * is compute unit id.
> +	 */
> +	cu = cpu_data(cpu).cpu_core_id;
> +
> +	rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR, &data->cu_acc_power[cu]);
> +}
> +
> +/*
> + * This function is only able to be called when CPUID
> + * Fn8000_0007:EDX[12] is set.
> + */
> +static int read_registers(struct fam15h_power_data *data)
> +{
> +	int this_cpu, ret, cpu;
> +	int target;
> +	cpumask_var_t mask;
> +
> +	ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
> +	if (!ret)
> +		return -ENOMEM;
> +
> +	get_online_cpus();
> +	this_cpu = get_cpu();

What now?

get_online_cpus() is enough.

> +
> +	/*
> +	 * Choose the first online core of each compute unit, and then
> +	 * read their MSR value of power and ptsc in a single IPI,
> +	 * because the MSR value of CPU core represent the compute
> +	 * unit's.
> +	 */
> +	for_each_online_cpu(cpu) {
> +		target = cpumask_first(topology_sibling_cpumask(cpu));
> +		if (!cpumask_test_cpu(target, mask))
> +			cpumask_set_cpu(target, mask);
> +	}

I think you want something like this: iterate over each core and put one
of them into the mask.

	core = -1;

	for_each_online_cpu(cpu) {
		this_core = topology_core_id(cpu);

		if (this_core == core)
			continue;

		core = this_core;

		/* get any CPU on this compute unit */
		cpumask_set_cpu(cpumask_any(topology_sibling_cpumask(cpu)), mask);
	}


Btw, tglx, peterz, do you guys think it would make sense to have a
generic helper:

	for_each_core(cpu)

which would give you any of the threads on the core in the @cpu var when
iterating?

I see only arch/x86/events/intel/cstate.c doing any comparisons with
topology_core_id() now but it might be useful...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [next] | [standalone]

#1365947

On Mon, Mar 28, 2016 at 11:29:52AM +0200, Borislav Petkov wrote:
> I think you want something like this: iterate over each core and put one
> of them into the mask.
> 
> 	core = -1;
> 
> 	for_each_online_cpu(cpu) {
> 		this_core = topology_core_id(cpu);
> 
> 		if (this_core == core)
> 			continue;
> 
> 		core = this_core;
> 
> 		/* get any CPU on this compute unit */
> 		cpumask_set_cpu(cpumask_any(topology_sibling_cpumask(cpu)), mask);
> 	}

This will not in fact work for Intel, nor if I manage to one day
randomize our CPU numbers on AMD.

[toc] | [prev] | [next] | [standalone]

#1365971

On Tue, Mar 29, 2016 at 09:31:58AM +0200, Peter Zijlstra wrote:
> This will not in fact work for Intel, nor if I manage to one day
> randomize our CPU numbers on AMD.

Oh, I know why. I have this 64 CPUs box here:

$ grep "core id" /proc/cpuinfo | uniq
core id         : 0
core id         : 8
core id         : 2
core id         : 10
core id         : 1
core id         : 9
core id         : 3
core id         : 11
core id         : 0
core id         : 8
core id         : 2
core id         : 10
core id         : 1
core id         : 9
core id         : 3
core id         : 11

Those core IDs repeat and are almost random too :)

I guess we'll need a mask. Maybe as a future exercise...

That box's topology has other funsies like this:

$ grep -E -B 2 "core id\s+: 0" /proc/cpuinfo
physical id     : 0
siblings        : 16
core id         : 0
--
physical id     : 1
siblings        : 16
core id         : 0
--
physical id     : 2
siblings        : 16
core id         : 0
--
physical id     : 3
siblings        : 16
core id         : 0
--
physical id     : 0
siblings        : 16
core id         : 0
--
physical id     : 1
siblings        : 16
core id         : 0
--
physical id     : 2
siblings        : 16
core id         : 0
--
physical id     : 3
siblings        : 16
core id         : 0

So in order to dig out which HT threads belong together, I need to look
at the (core id, physical id) pair.

I guess this is how we "fix" the schedulers of other OSes - by playing
topology games...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web