On 09/01/2015 08:56 AM, Borislav Petkov wrote:
On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
That is a matter of driver implementation. Very commonly hwmon drivers
implement value caching, where data from the device is only read at
minimum intervals, and the cached values are
On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
> That is a matter of driver implementation. Very commonly hwmon drivers
> implement value caching, where data from the device is only read at
> minimum intervals, and the cached values are reported if the information
> is polled too
On 09/01/2015 08:56 AM, Borislav Petkov wrote:
On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
That is a matter of driver implementation. Very commonly hwmon drivers
implement value caching, where data from the device is only read at
minimum intervals, and the cached values are
On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
> That is a matter of driver implementation. Very commonly hwmon drivers
> implement value caching, where data from the device is only read at
> minimum intervals, and the cached values are reported if the information
> is polled too
On 08/31/2015 01:44 PM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
On 08/31/2015 09:06 AM, Borislav Petkov wrote:
That's a good point - I missed that during previous review. Rui, please
put the rdmsrl_safe_on_cpu() accesses in a separate function
On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
> On 08/31/2015 09:06 AM, Borislav Petkov wrote:
> >That's a good point - I missed that during previous review. Rui, please
> >put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> >run on a particular CPU, for your
On 08/31/2015 09:06 AM, Borislav Petkov wrote:
On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
This means you can do much finer grained measurements than system wide
Well, we can do finer-grained if needed.
On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide
Well, we can do finer-grained if needed. I'm all for everything which
has a good use
On 08/31/2015 07:57 AM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
What does that have to do with 'hwmon' ? The current implementation in the
driver may not be a good idea, and maybe for good reasons; I can not
comment on that. However, you concluded
On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
> What does that have to do with 'hwmon' ? The current implementation in the
> driver may not be a good idea, and maybe for good reasons; I can not
> comment on that. However, you concluded from that implementation that
> hwmon, the
On 08/31/2015 06:38 AM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
So let me
On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> >On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> >>On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> >>>So let me withdraw my ack: the much more
On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
So let me withdraw my ack: the much more important question that I
missed first time around, why is this reporting feature
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> > So let me withdraw my ack: the much more important question that I
> > missed first time around, why is this reporting feature living in
> > hwmon, not in perf? We
On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
> What does that have to do with 'hwmon' ? The current implementation in the
> driver may not be a good idea, and maybe for good reasons; I can not
> comment on that. However, you concluded from that implementation that
> hwmon, the
On 08/31/2015 07:57 AM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
What does that have to do with 'hwmon' ? The current implementation in the
driver may not be a good idea, and maybe for good reasons; I can not
comment on that. However, you concluded
On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide
Well, we can do finer-grained if needed. I'm all for everything which
has a good use
On 08/31/2015 09:06 AM, Borislav Petkov wrote:
On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
This means you can do much finer grained measurements than system wide
Well, we can do finer-grained if needed.
On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
> On 08/31/2015 09:06 AM, Borislav Petkov wrote:
> >That's a good point - I missed that during previous review. Rui, please
> >put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> >run on a particular CPU, for your
On 08/31/2015 01:44 PM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
On 08/31/2015 09:06 AM, Borislav Petkov wrote:
That's a good point - I missed that during previous review. Rui, please
put the rdmsrl_safe_on_cpu() accesses in a separate function
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> > So let me withdraw my ack: the much more important question that I
> > missed first time around, why is this reporting feature living in
> > hwmon, not in perf? We
On 08/31/2015 06:38 AM, Peter Zijlstra wrote:
On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
So let me
On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
So let me withdraw my ack: the much more important question that I
missed first time around, why is this reporting feature
On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> >On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> >>On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> >>>So let me withdraw my ack: the much more
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> So let me withdraw my ack: the much more important question that I
> missed first time around, why is this reporting feature living in
> hwmon, not in perf? We have energy reporting facilities in perf that
> this should be synced to.
On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
So let me withdraw my ack: the much more important question that I
missed first time around, why is this reporting feature living in
hwmon, not in perf? We have energy reporting facilities in perf that
this should be synced to.
* Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > >
> > > In a subsequent patch, we will use this function in
* Ingo Molnar mi...@kernel.org wrote:
* Borislav Petkov b...@alien8.de wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this
On Thu, Aug 27, 2015 at 10:27:46AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> >
> > In a subsequent patch, we will use this function in
On Fri, Aug 28, 2015 at 04:04:18PM +0800, Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > >
> > > In a subsequent
On Fri, Aug 28, 2015 at 10:04:18AM +0200, Ingo Molnar wrote:
> Looks good to me in theory.
Thanks.
> I suspect we might want to factor the 'compute unit' logic out a bit
> more if usage becomes more widespread - but right now it's hwmon
> drivers only,right?
Yeah.
My angle is to extend stuff
* Borislav Petkov wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> >
> > In a subsequent patch, we will use this function in fam15h_power
> > driver.
> >
> >
On 08/27/2015 11:48 PM, Borislav Petkov wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
>
> In a subsequent patch, we will use this function in fam15h_power
> driver.
>
> Signed-off-by: Huang Rui
> ---
>
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
On 08/27/2015 11:48 PM, Borislav Petkov wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by:
On Fri, Aug 28, 2015 at 04:04:18PM +0800, Ingo Molnar wrote:
* Borislav Petkov b...@alien8.de wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent
On Fri, Aug 28, 2015 at 10:04:18AM +0200, Ingo Molnar wrote:
Looks good to me in theory.
Thanks.
I suspect we might want to factor the 'compute unit' logic out a bit
more if usage becomes more widespread - but right now it's hwmon
drivers only,right?
Yeah.
My angle is to extend stuff as we
On Thu, Aug 27, 2015 at 10:27:46AM -0700, Guenter Roeck wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
* Borislav Petkov b...@alien8.de wrote:
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
>
> In a subsequent patch, we will use this function in fam15h_power
> driver.
>
> Signed-off-by: Huang Rui
> ---
>
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by: Huang Rui
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/cpu/amd.c| 19
On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.
In a subsequent patch, we will use this function in fam15h_power
driver.
Signed-off-by: Huang Rui ray.hu...@amd.com
---
arch/x86/include/asm/processor.h | 1 +
arch/x86/kernel/cpu/amd.c|
44 matches
Mail list logo
