lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151026034615.GE8036@hr-amur2>
Date:	Mon, 26 Oct 2015 11:46:16 +0800
From:	Huang Rui <ray.huang@....com>
To:	Borislav Petkov <bp@...e.de>
CC:	Guenter Roeck <linux@...ck-us.net>,
	Peter Zijlstra <peterz@...radead.org>,
	Jean Delvare <jdelvare@...e.de>,
	Andy Lutomirski <luto@...capital.net>,
	Andreas Herrmann <herrmann.der.user@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Len Brown <lenb@...nel.org>,
	John Stultz <john.stultz@...aro.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	<lm-sensors@...sensors.org>, <linux-kernel@...r.kernel.org>,
	<x86@...nel.org>,
	Andreas Herrmann <herrmann.der.user@...glemail.com>,
	Aravind Gopalakrishnan <Aravind.Gopalakrishnan@....com>,
	Fengguang Wu <fengguang.wu@...el.com>,
	Aaron Lu <aaron.lu@...el.com>, Tony Li <tony.li@....com>
Subject: Re: [PATCH v2 07/10] hwmon: (fam15h_power) Introduce a cpu
 accumulated power reporting algorithm

On Fri, Oct 23, 2015 at 03:28:02PM +0200, Borislav Petkov wrote:
> On Tue, Oct 20, 2015 at 10:28:26AM +0800, Huang Rui wrote:
> > This patch introduces an algorithm that computes the average power by
> > reading a delta value of “core power accumulator” register during
> > measurement interval, and then dividing delta value by the length of
> > the time interval.
> > 
> > User is able to use power1_average entry to measure the processor power
> > consumption and power1_average_interval entry to set the interval.
> > 
> > A simple example:
> > 
> > ray@...ub:~/tip$ sensors
> > fam15h_power-pci-00c4
> > Adapter: PCI adapter
> > power1:       23.73 mW (avg = 634.63 mW, interval =   0.01 s)
> >                        (crit =  15.00 W)
> > 
> > ...
> 
> I need to play with this more after I get back from KS. Just a partial
> review for now.
> 

Sounds good.

> > 
> > The result is current average processor power consumption in 10
> > millisecond. The unit of the result is uWatt.
> > 
> > Suggested-by: Guenter Roeck <linux@...ck-us.net>
> > Signed-off-by: Huang Rui <ray.huang@....com>
> > Cc: Borislav Petkov <bp@...en8.de>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Ingo Molnar <mingo@...nel.org>
> > ---
> >  drivers/hwmon/fam15h_power.c | 120 +++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 120 insertions(+)
> > 
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index 6321f73..a5a539e 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -26,6 +26,9 @@
> >  #include <linux/pci.h>
> >  #include <linux/bitops.h>
> >  #include <linux/cpumask.h>
> > +#include <linux/mutex.h>
> > +#include <linux/time.h>
> > +#include <linux/sched.h>
> >  #include <asm/processor.h>
> >  #include <asm/msr.h>
> >  
> > @@ -64,6 +67,10 @@ struct fam15h_power_data {
> >  	u64 cu_acc_power[MAX_CUS];
> >  	/* performance timestamp counter */
> >  	u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > +	/* online/offline status of current compute unit */
> > +	int cu_on[MAX_CUS];
> > +	unsigned long power_period;
> > +	struct mutex acc_pwr_mutex;
> >  };
> >  
> >  static ssize_t show_power(struct device *dev,
> > @@ -132,11 +139,15 @@ static void do_read_registers_on_cu(void *_data)
> >  	cores_per_cu = amd_get_cores_per_cu();
> >  	cu = cpu / cores_per_cu;
> >  
> > +	mutex_lock(&data->acc_pwr_mutex);
> >  	WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
> >  			    &data->cu_acc_power[cu]));
> >  
> >  	WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
> >  			    &data->cpu_sw_pwr_ptsc[cu]));
> > +
> > +	data->cu_on[cu] = 1;
> > +	mutex_unlock(&data->acc_pwr_mutex);
> >  }
> >  
> >  static int read_registers(struct fam15h_power_data *data)
> > @@ -148,6 +159,10 @@ static int read_registers(struct fam15h_power_data *data)
> >  	cores_per_cu = amd_get_cores_per_cu();
> >  	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >  
> > +	mutex_lock(&data->acc_pwr_mutex);
> > +	memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
> > +	mutex_unlock(&data->acc_pwr_mutex);
> > +
> >  	WARN_ON_ONCE(cu_num > MAX_CUS);
> >  
> >  	ret = zalloc_cpumask_var(&mask, GFP_KERNEL);
> > @@ -184,18 +199,113 @@ static int read_registers(struct fam15h_power_data *data)
> >  	return 0;
> >  }
> >  
> > +static ssize_t acc_show_power(struct device *dev,
> > +			      struct device_attribute *attr,
> > +			      char *buf)
> > +{
> > +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> > +	u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
> > +	    jdelta[MAX_CUS];
> > +	u64 tdelta, avg_acc;
> > +	int cu, cu_num, cores_per_cu, ret;
> > +	signed long leftover;
> > +
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	ret = read_registers(data);
> > +	if (ret)
> > +		return 0;
> > +
> > +	cu = 0;
> > +	while(cu++ < cu_num) {
> > +		prev_cu_acc_power[cu] = data->cu_acc_power[cu];
> > +		prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
> > +	}
> 
> Please integrate checkpatch into your workflow of creating patches - it
> can be correct sometimes:
> 
> ERROR: space required before the open parenthesis '('
> #130: FILE: drivers/hwmon/fam15h_power.c:221:
> +       while(cu++ < cu_num) {
> 

Oh, I will take care next time.

> 
> > +
> > +	leftover = schedule_timeout_interruptible(
> > +			msecs_to_jiffies(data->power_period)
> > +		   );
> 
> This way of writing a function call is reaaally ugly. What's wrong with:
> 
> 	leftover = schedule_timeout_interruptible(msecs_to_jiffies(data->power_period));
> 
> ?
> 
> And don't tell me 80 columns - that rule is not a hard one.
> 

Actually, yes. I found it too long, so... :)
OK, I will fix it on V3.


Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ