On Fri, 4 Dec 2015 09:22:56 +0100
Peter Zijlstra wrote:
> Also, yuck @ powercap/intel_rapl.c for doing rdmsr_on_cpu() +
> wrmsr_on_cpu() all over the place.
Can you please be more specific? is the concern related to the
overhead of IPI? I am doing these calls based on MSR CPU scope and
consider t
On Fri, 4 Dec 2015 12:53:35 +0100
Ingo Molnar wrote:
>
> * Borislav Petkov wrote:
>
> > On Fri, Dec 04, 2015 at 11:41:03AM +0100, Paolo Bonzini wrote:
> > > No, please don't. Why do you need a wrmsr instead of a rdmsr? If
> > > there's no RAPL domains, the device doesn't load. On hypervisor
On Thu, 3 Dec 2015 19:42:41 +0100
Borislav Petkov wrote:
> No, those are going away:
>
> https://lkml.kernel.org/r/1448982023-19187-4-git-send-email...@alien8.de
>
> Next on my TODO is killing the rest of them.
Fair enough.
Acked-by: Jacob Pan
--
To unsubscribe from this list
On Thu, 3 Dec 2015 19:27:02 +0100
Borislav Petkov wrote:
>
> + if (boot_cpu_has(X86_FEATURE_HYPERVISOR))
> + return 0;
> +
or use this?
#define cpu_has_hypervisor boot_cpu_has(X86_FEATURE_HYPERVISOR)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel
On Fri, 27 Nov 2015 10:17:02 +0100
Ingo Molnar wrote:
> > > > Two sysctl knobs are given to the userspace for selecting the
> > > > percentage of idle time as well as the forced idle duration for
> > > > each idle period injected.
> > >
> > > What's the purpose of these knobs? Just testing,
On Tue, 24 Nov 2015 12:00:07 +
Javi Merino wrote:
> > - you first set 50% idle
> > - then launch 6 busy loops
>
> Correct
Do you mind sharing the workload or test scripts? Just to reproduce
here.
Thanks,
Jacob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
pt(5ms);
> end = now + 5ms:
> while (now < end)
> mwait();
> }
[Jacob Pan]
--
To unsubscribe from this list: send the line &quo
On Tue, 24 Nov 2015 11:09:56 +0100
Peter Zijlstra wrote:
> On Tue, Nov 24, 2015 at 09:12:40AM +, Javi Merino wrote:
> > On Mon, Nov 23, 2015 at 07:07:06PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 23, 2015 at 05:56:44PM +, Javi Merino wrote:
> > > > I've tested this series on Juno (2
On Mon, 23 Nov 2015 10:46:57 -0800
Jacob Pan wrote:
> Broxton is Atom based SoC which supports RAPL interface
> that is compatible with Core.
Nevermind, already in. sorry i lost track.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a m
Broxton is Atom based SoC which supports RAPL interface
that is compatible with Core.
Signed-off-by: Jacob Pan
---
drivers/powercap/intel_rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 5efacd0..bfc353b 100644
--- a
On Thu, 19 Nov 2015 17:24:07 +
Morten Rasmussen wrote:
> I could see this technique being useful within the SoC as well.
> Synchronized idle injection on all cpus in a cluster would allow us to
> reach cluster idle states where resources shared within the cluster
> can be gated or powered off
On Thu, 19 Nov 2015 20:59:05 +0100
Peter Zijlstra wrote:
> On Thu, Nov 19, 2015 at 11:21:25AM -0800, Jacob Pan wrote:
> > On Thu, 19 Nov 2015 20:06:30 +0100
> > Peter Zijlstra wrote:
> >
> > > Which one? That is, I cannot find a idle_cpu() call from
> >
On Thu, 19 Nov 2015 20:06:30 +0100
Peter Zijlstra wrote:
> Which one? That is, I cannot find a idle_cpu() call from
> tick_nohz_irq_exit().
it is tick_irq_exit(void), i will not call tick_nohz_irq_exit() if
!idle_cpu()
please see my other email for complete story. pasted below.
I am not sure w
On Mon, 16 Nov 2015 16:09:10 -0800
Jacob Pan wrote:
> > > For the second case, which is much more rare, I think we do have
> > > next timer exactly one tick away. Just don't know why tick will
> > > continue into idle loop.
> >
> > Well, it shou
On Thu, 19 Nov 2015 14:39:35 +
Javi Merino wrote:
> > +
>
> One minor nit: can you use key=value (i.e. "throttled=%d") instead for
> consistency with the rest of this file?
>
will do.
> Other than that, I know that Peter suggested an enum for the action,
> but wouldn't it be better to cr
On Mon, 12 Oct 2015 11:45:20 -0700
"Hall, Christopher S" wrote:
took a while to read the code, i have a few comments/questions
>
> diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
> index c3f7602..c3f098c 100644
> --- a/arch/x86/kernel/tsc.c
> +++ b/arch/x86/kernel/tsc.c
> @@ -820,7 +820
On Wed, 18 Nov 2015 16:21:27 +0100 (CET)
Thomas Gleixner wrote:
> >
> > > Okay. But it does mean that the defeault idle period is 5 ticks
> > > (50ms @ HZ=100) and not 5 ms
> > correct. my reason is to scale with various HZ values.
>
> So for smaller HZ values we get longer disruption. Th
On Wed, 18 Nov 2015 15:09:44 +
Morten Rasmussen wrote:
> Okay. But it does mean that the defeault idle period is 5 ticks (50ms
> @ HZ=100) and not 5 ms
correct. my reason is to scale with various HZ values.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
On Wed, 18 Nov 2015 14:04:41 +
Morten Rasmussen wrote:
> Then I'm confused :-/
>
> I see the hrtimers, but the actual idle duration appears to be in
> ticks rather than ms and then converted later.
>
> +/* Duration of idle time in ticks of each injection period
> */ +unsigned int sysctl_sch
On Wed, 18 Nov 2015 09:36:22 +0100
Ingo Molnar wrote:
> >
> > This patch introduces a scheduler based idle injection method, it
> > works by blocking CFS runqueue synchronously and periodically. The
> > actions on all online CPUs are orchestrated by per CPU hrtimers.
> >
> > Two sysctl knobs ar
On Tue, 17 Nov 2015 11:24:49 +0100
Peter Zijlstra wrote:
> On Mon, Nov 16, 2015 at 09:04:03PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 16, 2015 at 06:57:14PM -0800, Arjan van de Ven wrote:
> > > On 11/16/2015 6:53 PM, Paul E. McKenney wrote:
> > > >Fair point. When in the five-jiffy thrott
On Mon, 16 Nov 2015 23:01:12 +0100 (CET)
Thomas Gleixner wrote:
> > For the second case, which is much more rare, I think we do have
> > next timer exactly one tick away. Just don't know why tick will
> > continue into idle loop.
>
> Well, it should not be hard to figure that out. There are no
On Mon, 16 Nov 2015 15:32:38 -0800
Arjan van de Ven wrote:
> On 11/16/2015 3:28 PM, Paul E. McKenney wrote:
>
> > Is this mostly an special-purpose embedded thing, or do you expect
> > distros to be enabling this? If the former, I suggest
> > , but if distros are doing this for
> > general-purp
On Mon, 16 Nov 2015 14:31:17 -0800
"Paul E. McKenney" wrote:
> > Either one works but my concern is that users may not realize the
> > intricate CONFIG_ options and how they translate into energy
> > savings. Consulted with Josh, it seems we could add a check here to
> > recognize the forced idle
On Mon, 16 Nov 2015 14:31:17 -0800
"Paul E. McKenney" wrote:
> Just out of curiosity, what is the purpose of the forced idle state?
> Thermal control or some such?
yes. for thermal control or power capping. I have some description in
cover letter.
https://lwn.net/Articles/664405/
Thanks,
Jacob
-
On Mon, 16 Nov 2015 16:06:57 +0100 (CET)
Thomas Gleixner wrote:
> > -0 [000]30.093474: bprint:
> > __tick_nohz_idle_enter: JPAN: tick_nohz_stop_sched_tick 609 delta
> > 100 [JP] but sees delta is exactly 1 tick away. didn't stop
> > tick.
>
> If the delta is 1 tick then i
On Fri, 13 Nov 2015 15:13:45 -0500 (EST)
Thomas Gleixner wrote:
> >
> > +static inline ktime_t ktime_roundup(ktime_t x, ktime_t y)
>
> Kerneldoc comment of this function would be appreciated.
will do. Plan to reuse John's comment.
Thanks,
Jacob
--
To unsubscribe from this list: send the lin
On Fri, 13 Nov 2015 12:11:01 -0800
John Stultz wrote:
> Could you add a comment as to what the function does, and use some
> better variable names here to make it more immediately obvious what is
> being done here?
>
> Something like:
> /**
> * ktime_roundup - Rounds value up to interval chunk
On Fri, 13 Nov 2015 15:22:16 -0500 (EST)
Thomas Gleixner wrote:
>
>
> On Fri, 13 Nov 2015, Jacob Pan wrote:
>
> > Upon entering idle, we can turn off tick if the next timeout
> > is exactly one tick away. Otherwise, we could enter inner idle loop
> > with tick
ag is introduced to combine forced idle and
nr_running.
Signed-off-by: Jacob Pan
---
include/linux/sched.h| 11 ++
include/linux/sched/sysctl.h | 5 +
init/Kconfig | 10 ++
kernel/sched/fair.c | 353 ++-
kernel/sched/sc
Upon entering idle, we can turn off tick if the next timeout
is exactly one tick away. Otherwise, we could enter inner idle loop
with tick still enabled, without resched set, the tick will continue
during idle therefore less optimal in terms of energy savings.
Signed-off-by: Jacob Pan
LinuxCon where data/graph can be seen
from slides #18 and later.
http://events.linuxfoundation.org/sites/events/files/slides/LinuxCon_Japan_2015_idle_injection1_0.pdf
RFC discussions are here.
https://lkml.org/lkml/2015/11/2/756
Thanks,
Jacob
Jacob Pan (4):
ktime: add a roundup function
timer
ktime roundup function can be used to keep timer aligned and
prevent drift for recurring timeouts.
Signed-off-by: Jacob Pan
---
include/linux/ktime.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index 2b6a204..2e293fa 100644
--- a
Trace events for idle injection can be used to determine
timer activities for checking synchronization. In addition they
also helps to determine when the runqueue is throttled.
Signed-off-by: Jacob Pan
---
include/linux/sched.h| 5 +
include/trace/events/sched.h | 25
On Tue, 10 Nov 2015 14:23:24 +0100
Peter Zijlstra wrote:
> > +/* protect injection parameters from runtime changes */
> > +static DEFINE_SPINLOCK(idle_inject_lock);
>
> A global lock, yay :-), I think you want this to be a RAW_SPINLOCK
> though. As on -RT this would want to actually run from I
On Tue, 10 Nov 2015 18:00:10 +0100
Peter Zijlstra wrote:
> > Different per CPU timer may intercept parameter changes at slightly
> > different time, so there is a race condition such that some CPUs may
> > catch the period change later by one period, which results in a
> > correct period change b
On Tue, 10 Nov 2015 17:36:46 +0100
Peter Zijlstra wrote:
> > The downside is that we need to restart the timers every time if
> > user were to change injection parameters, i.e. duration and percent.
> > Or do locking which might be too expensive. In the previous
> > approach, it will naturally ca
On Tue, 10 Nov 2015 15:58:23 +0100
Peter Zijlstra wrote:
> On Tue, Nov 10, 2015 at 06:01:16AM -0800, Jacob Pan wrote:
> > On Tue, 10 Nov 2015 14:23:24 +0100
> > Peter Zijlstra wrote:
>
> > > It looks like what you want is:
> > >
On Tue, 10 Nov 2015 14:23:24 +0100
Peter Zijlstra wrote:
> > +static enum hrtimer_restart idle_inject_timer_fn(struct hrtimer
> > *hrtimer) +{
> > + struct hrtimer *hrt = this_cpu_ptr(&idle_inject_timer);
> > + int cpu = smp_processor_id();
> > + ktime_t now, delta, period;
> > + bool sta
ktime roundup function can be used to keep timer aligned and
prevent drift for recurring timeouts.
Signed-off-by: Jacob Pan
---
include/linux/ktime.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index 2b6a204..2e293fa 100644
--- a
r CPU hrtimers.
Two sysctl knobs are given to the userspce for selecting the
percentage of idle time as well as the forced idle duration for each
idle period injected.
Since only CFS class is targeted, other high priority tasks are not
affected, such as RT, softirq, and interrupts.
Signed-off-by: Jaco
cient to do C-states insertion
if coordinated.
Looking forward, there are use case beyond thermal/power capping. I think
we can consolidate ballanced partial busy workload that are evenly
distributed among CPUs.
Please let me know what you think.
Thanks,
Jacob Pan (3):
ktime: add a ro
Upon entering idle, we can turn off tick if the next timeout
is exactly one tick away. Otherwise, we could enter inner idle loop
with tick still enabled, without resched set, the tick will continue
during idle therefore less optimal in terms of energy savings.
Signed-off-by: Jacob Pan
On Fri, 6 Nov 2015 15:49:29 -0800
Jacob Pan wrote:
> > Check the softirq stuff before calling throttle ?
>
> yes, played with it but it seems there are other cases causing pending
> softirq in idle in addition to throttle. I still haven't figure it
> out, this problem
On Fri, 6 Nov 2015 21:55:49 +
Dietmar Eggemann wrote:
> > what i am interested is not per cpu idle state but rather at the
> > package level or domain. It must be an indication for the
> > overlapped idle time. Usually has to come from HW counters.
>
> I see. We have a similar problem with
On Mon, 9 Nov 2015 15:15:34 +0100
Peter Zijlstra wrote:
> On Mon, Nov 09, 2015 at 11:56:51AM +, Punit Agrawal wrote:
> > Jacob Pan writes:
> > > My take is that RT and throttling will never go well together
> > > since they are conflicting in principle.
> >
On Mon, 09 Nov 2015 11:56:51 +
Punit Agrawal wrote:
> > actually, I was suggesting to start considering idle injection once
> > frequency capped to the energy efficient point, which can be much
> > higher than the lowest frequency. The idea being, deep idle power is
> > negligible compared to
On Fri, 6 Nov 2015 08:45:10 +0100
Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 03:36:25PM -0800, Jacob Pan wrote:
>
> > I did some testing with the code below, it shows random
> > [ 150.442597] NOHZ: local_softirq_pending 02
> > [ 153.032673] NOHZ: l
On Fri, 06 Nov 2015 16:50:15 +
Punit Agrawal wrote:
> * idle injection once frequencies have been capped to the lowest
> feasible values (as suggested in the cover letter)
>
actually, I was suggesting to start considering idle injection once
frequency capped to the energy efficient point,
On Fri, 6 Nov 2015 18:30:01 +
Dietmar Eggemann wrote:
> On 05/11/15 10:12, Peter Zijlstra wrote:
> >
> > People, trim your emails!
> >
> > On Wed, Nov 04, 2015 at 08:58:30AM -0800, Jacob Pan wrote:
> >
> >>> I also like #2 too. Specially n
idle)
> + return NULL;
> +
> /*
>* This is OK, because current is on_cpu, which avoids it
> being picked
>* for load-balance and preemption/IRQs are still disabled
> avoiding diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> index efd3bfc..33d355d 100644
> --- a/kernel/sched/sched.h
> +++ b/kernel/sched/sched.h
> @@ -347,6 +347,7 @@ struct cfs_bandwidth { };
> struct cfs_rq {
> struct load_weight load;
> unsigned int nr_running, h_nr_running;
> + unsigned int runnable, forced_idle;
>
> u64 exec_clock;
> u64 min_vruntime;
[Jacob Pan]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 5 Nov 2015 11:27:32 -0800
Jacob Pan wrote:
> On Thu, 5 Nov 2015 11:09:22 +0100
> Peter Zijlstra wrote:
>
> > > Before:
> > > CPU0 __||| || |___| || || |_
> > > CPU1 _||| || |___| || |___
&
On Thu, 5 Nov 2015 11:09:22 +0100
Peter Zijlstra wrote:
> > Before:
> > CPU0 __||| || |___| || || |_
> > CPU1 _||| || |___| || |___
> >
> > After:
> >
> > CPU0 __||| || |___| || || |_
> > CPU1 __||| || |___| || |___
> >
> > Th
On Thu, 5 Nov 2015 15:33:32 +0100
Peter Zijlstra wrote:
> On Thu, Nov 05, 2015 at 06:22:58AM -0800, Arjan van de Ven wrote:
> > On 11/5/2015 2:09 AM, Peter Zijlstra wrote:
> >
> > >I can see such a scheme having a fairly big impact on latency,
> > >esp. with forced idleness such as this. That's
On Tue, 3 Nov 2015 22:06:55 -0800
Eduardo Valentin wrote:
> Hello Jacob,
>
> On Mon, Nov 02, 2015 at 04:10:25PM -0800, Jacob Pan wrote:
> > Hi Peter and all,
> >
> > A while ago, we had discussion about how powerclamp is broken in the
> > sense of turning
On Tue, 3 Nov 2015 14:31:20 +0100
Peter Zijlstra wrote:
> > @@ -5136,6 +5148,16 @@ pick_next_task_fair(struct rq *rq, struct
> > task_struct *prev) struct task_struct *p;
> > int new_tasks;
> >
> > +#ifdef CONFIG_CFS_IDLE_INJECT
> > + if (cfs_rq->force_throttled &&
> > + !idle_c
On Tue, 3 Nov 2015 14:31:20 +0100
Peter Zijlstra wrote:
> > @@ -5136,6 +5148,16 @@ pick_next_task_fair(struct rq *rq, struct
> > task_struct *prev) struct task_struct *p;
> > int new_tasks;
> >
> > +#ifdef CONFIG_CFS_IDLE_INJECT
> > + if (cfs_rq->force_throttled &&
> > + !idle_c
coordinated.
Looking forward, there are use case beyond thermal/power capping. I think
we can consolidate ballanced partial busy workload that are evenly
distributed among CPUs.
Please let me know what you think.
Thanks,
Jacob Pan (3):
ktime: add a roundup function
timer: relax tick stop in
r CPU hrtimers.
Two sysctl knobs are given to the userspce for selecting the
percentage of idle time as well as the forced idle duration for each
idle period injected.
Since only CFS class is targeted, other high priority tasks are not
affected, such as RT and interrupts.
Signed-off-by: Jaco
Upon entering idle, we can turn off tick if the next timeout
is exactly one tick away. Otherwise, we could enter inner idle loop
with tick still enabled, without resched set, the tick will continue
during idle therefore less optimal in terms of energy savings.
Signed-off-by: Jacob Pan
ktime roundup function can be used to keep timer aligned and
prevent drift for recurring timeouts.
Signed-off-by: Jacob Pan
---
include/linux/ktime.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/include/linux/ktime.h b/include/linux/ktime.h
index 2b6a204..2e293fa 100644
--- a
On Fri, 2 Oct 2015 09:50:45 +
Olaf Hering wrote:
> The header might be in /usr/include/ncursesw, which is not
> part of the standard include path. This fixes compile on openSUSE.
>
Acked:by: Jacob Pan
thanks
> Signed-off-by: Olaf Hering
> ---
> tools/thermal
OKOKOK
>> ___
*DC = don't compile.
The problem is the case when RAPL=y, IOSF=m.
Jacob
> Pengyu
>
> On 09/25/2015 12:33 AM, Jacob Pan wrote:
> > On Thu, 24 Sep 2015 18:03:32 +0800
> > Pengyu Ma wro
On Thu, 24 Sep 2015 18:03:32 +0800
Pengyu Ma wrote:
> > So the problematic case is when RAPL=Y IOSF=M
> > Since real IOSF functions are available when
> > #if IS_ENABLED(CONFIG_IOSF_MBI)
> > There will be no dummy functions for RAPL to reference in this
> > case.
> iosf_mbi_write/read will warn
On Tue, 22 Sep 2015 11:11:36 +0800
Pengyu Ma wrote:
>
>
> On 09/22/2015 05:36 AM, Jacob Pan wrote:
> > On Mon, 21 Sep 2015 11:48:14 +0800
> > Pengyu Ma wrote:
> >
> >>
> >> On 09/18/2015 11:43 PM, Jacob Pan wrote:
> >>> On Fri, 18
On Tue, 22 Sep 2015 09:41:52 -0400
Austin S Hemmelgarn wrote:
> On 2015-09-21 17:36, Jacob Pan wrote:
> > On Mon, 21 Sep 2015 11:48:14 +0800
> > Pengyu Ma wrote:
> >
> >>
> >>
> >> On 09/18/2015 11:43 PM, Jacob Pan wrote:
> >>> On Fri,
On Mon, 21 Sep 2015 11:48:14 +0800
Pengyu Ma wrote:
>
>
> On 09/18/2015 11:43 PM, Jacob Pan wrote:
> > On Fri, 18 Sep 2015 02:09:55 +0200
> > "Rafael J. Wysocki" wrote:
> >
> >> On Thursday, September 17, 2015 03:31:41 PM Pengyu Ma wrote:
APL Support"
> > - depends on X86 && IOSF_MBI
> > + depends on X86
> > default n
> > ---help---
> > This enables support for the Intel Running Average Power
> > Limit (RAPL)
> >
>
[Jacob Pan]
--
To unsubscribe fr
Add support for Intel Denlow UP server platform.
Signed-off-by: Jacob Pan
---
drivers/thermal/intel_powerclamp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 725718e..d534357 100644
--- a/drivers/thermal
On Mon, 15 Jun 2015 13:32:01 -0400 (EDT)
Vince Weaver wrote:
> On Thu, 26 Mar 2015, Jacob Pan wrote:
>
> > RAPL energy hardware unit can vary within a single CPU package, e.g.
> > HSW server DRAM has a fixed energy unit of 15.3 uJ (2^-16) whereas
> > the unit on other d
On Tue, 26 May 2015 11:47:39 -0700
Dasaratharaman Chandramouli
wrote:
> Knights Landing DRAM RAPL supports PKG and DRAM RAPL domains.
> DRAM RAPL has a different fixed energy unit (2^-16J) similar to
> that of HSW.
>
Acked-by: Jacob Pan
> Signed-off-by: Dasaratharam
RAPL_CPU(0x4A, rapl_defaults_atom),/* Tangier */
> > RAPL_CPU(0x56, rapl_defaults_core),/* Future Xeon */
> > RAPL_CPU(0x5A, rapl_defaults_atom),/* Annidale */
> > + RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights
> > Landing */ {}
> > };
> > MO
On Fri, 8 May 2015 03:39:04 +0930
Anand Moon wrote:
> To install tmon we issue "make install" which produces bellow error.
>
looks good, there is no config file for now.
Thanks for the fix.
Acked-by: Jacob Pan
> root@odroidxu3:/usr/src/odroidxu3-4.y-testing/tools/t
.
Reported-by: Kristen Carlson Accardi
Signed-off-by: Jacob Pan
---
drivers/thermal/intel_powerclamp.c | 80 --
1 file changed, 43 insertions(+), 37 deletions(-)
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
index 12623bc
On Fri, 24 Apr 2015 10:33:34 -0700
Dasaratharaman Chandramouli
wrote:
> Adding Jacob Pan
>
> On Fri, 2015-04-17 at 15:31 -0700, Dasaratharaman Chandramouli wrote:
> > This patch enables intel_powerclamp driver to run on the
> > next-generation Intel(R) Xeon Phi Microarchit
Commit-ID: 645523960102fa0ac0578d070630e49ab05f06d1
Gitweb: http://git.kernel.org/tip/645523960102fa0ac0578d070630e49ab05f06d1
Author: Jacob Pan
AuthorDate: Thu, 26 Mar 2015 14:28:45 -0700
Committer: Ingo Molnar
CommitDate: Fri, 17 Apr 2015 09:58:56 +0200
perf/x86/intel/rapl: Fix
On Wed, 15 Apr 2015 17:40:59 +0200
Peter Zijlstra wrote:
> On Wed, Apr 15, 2015 at 08:08:07AM -0700, Jacob Pan wrote:
> > Any more comments? This is really a bug fix.
>
> I had it queued but it missed the first pull req, I'll put it in
> /urgent.
Thanks, just for my
On Mon, 6 Apr 2015 10:30:33 -0700
Stephane Eranian wrote:
> On Mon, Apr 6, 2015 at 8:21 AM, Jacob Pan
> wrote:
> >
> > On Thu, 26 Mar 2015 14:28:45 -0700
> > Jacob Pan wrote:
> >
> > > RAPL energy hardware unit can vary within a single CPU package,
> &
On Thu, 09 Apr 2015 14:18:49 +0100
Jonathan Cameron wrote:
> On 06/04/15 19:38, Jacob Pan wrote:
> > Commit 65de7654d39c70c2b ("iio: iio: Fix iio_channel_read return if
> > channel havn't info") added a check for valid info masks.
> >
> > This patch a
Validated RAPL functions on this platform. Add support to driver.
Signed-off-by: Jacob Pan
---
drivers/powercap/intel_rapl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 63d4033..678ac8c 100644
--- a/drivers/powercap
Broadwell server has support for package C-states, idle injection works
as expected on this platform.
Signed-off-by: Jacob Pan
---
drivers/thermal/intel_powerclamp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/thermal/intel_powerclamp.c
b/drivers/thermal/intel_powerclamp.c
On Sat, 21 Mar 2015 12:07:03 +
Jonathan Cameron wrote:
> > - .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
> > + .info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED)
> > + | BIT(IIO_CHAN_INFO_RAW),
> > },
> These cases strike me as problematic. You sho
Signed-off-by: Jacob Pan
---
drivers/iio/adc/axp288_adc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
index 08bcfb0..56008a8 100644
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_adc.c
@
On Thu, 26 Mar 2015 14:28:45 -0700
Jacob Pan wrote:
> RAPL energy hardware unit can vary within a single CPU package, e.g.
> HSW server DRAM has a fixed energy unit of 15.3 uJ (2^-16) whereas
> the unit on other domains can be enumerated from power unit MSR.
> There might be other v
special handling of certain cpus.
hw_unit is also removed from per cpu data since it is not per cpu
and the sampling rate for energy counter is typically not high.
Without this patch, DRAM domain on HSW servers will be counted
4x higher than the real energy counter.
Signed-off-by: Jacob Pan
---
arch
special handling of certain cpus.
hw_unit is also removed from per cpu data since it is not per cpu
and the sampling rate for energy counter is typically not high.
Without this patch, DRAM domain on HSW servers will be counted
4x higher than the real energy counter.
Signed-off-by: Jacob Pan
---
arch
Signed-off-by: Jacob Pan
---
drivers/iio/adc/axp288_adc.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/axp288_adc.c b/drivers/iio/adc/axp288_adc.c
index 08bcfb0..7ce361c 100644
--- a/drivers/iio/adc/axp288_adc.c
+++ b/drivers/iio/adc/axp288_
On Thu, 12 Mar 2015 17:50:20 -0500
kazutomo wrote:
> On 03/12/2015 05:05 PM, Jacob Pan wrote:
> > On Thu, 12 Mar 2015 16:59:43 -0500
> > kazutomo wrote:
> >
> >>> according to the document, future DRAM energy unit will always be
> >>> hardcoded to 15
unit to override package energy unit if non zero.
Please see this document for details.
"Intel Xeon Processor E5-1600 and E5-2600 v3 Product Families, Volume 2
of 2. Datasheet, September 2014, Reference Number: 330784-001 "
Signed-off-by: Jacob Pan
---
drivers/powercap/intel_r
On Thu, 12 Mar 2015 16:59:43 -0500
kazutomo wrote:
> > according to the document, future DRAM energy unit will always be
> > hardcoded to 15.3uJ, no enumeration since there is no domain
> > specific MSR for energy unit.
> Which document are you referring to?
Intel DocID:330784-001 Sept 2014
Int
An easier
> solution would be to maintain the unit in pJ, instead of uJ.
> or am I worrying too much? I guess the RAPL energy estimation may
> have some error, so maybe canceling out.
>
yes, you are right. using pJ or more precise shift would be a better.
let me add that also.
Thanks
On Wed, 11 Mar 2015 23:01:30 +0100
"Rafael J. Wysocki" wrote:
> On Wednesday, March 11, 2015 05:55:09 AM Jacob Pan wrote:
> > The current driver assumes all RAPL domains within a CPU package
> > have the same energy unit. This is no longer true for HSW server
> >
.
Signed-off-by: Jacob Pan
---
drivers/powercap/intel_rapl.c | 35 ---
1 file changed, 28 insertions(+), 7 deletions(-)
diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
index 97b5e4e..af4c61e 100644
--- a/drivers/powercap/intel_rapl.c
+++ b
ng. Better suggestions
> are welcome.
>
Good improvements.
Acked-by: Jacob Pan
> Thanks,
> Brian
>
> Brian Norris (8):
> tools/thermal: tmon: add --target-temp parameter
> tools/thermal: tmon: add min/max macros
> tools/thermal: tmon: tui: don't hard-code dia
d Brandt
Looks good to me with a few small things below. Otherwise,
Acked-by: Jacob Pan
> ---
> drivers/power/Kconfig |9 +
> drivers/power/Makefile|1 +
> drivers/power/axp288_fuel_gauge.c | 1148
> + 3 fi
On Wed, 7 Jan 2015 13:24:50 -0800
Todd E Brandt wrote:
> mfd/axp20x: change battery cell name to fuel gauge
>
Acked-by: Jacob Pan
> Name changes to the battery cell structure to a
> more generic cell type: fuel gauge.
>
> Signed-off-by: Todd Brandt
>
> d
On Wed, 7 Jan 2015 13:25:52 -0800
Todd E Brandt wrote:
> mfd/axp20x: add support for fuel gauge cell
>
Acked-by: Jacob Pan
> Register definitions and platform data structure
> for fuel gauge cell devices.
>
> Signed-off-by: Todd Brandt
>
> include
On Sat, 20 Dec 2014 07:01:12 +0530
Preeti U Murthy wrote:
> On 12/20/2014 01:26 AM, Thomas Gleixner wrote:
> > On Fri, 19 Dec 2014, Jacob Pan wrote:
> >
> >> On Thu, 18 Dec 2014 22:12:57 +0100 (CET)
> >> Thomas Gleixner wrote:
> >>
> >>> O
On Thu, 18 Dec 2014 22:12:57 +0100 (CET)
Thomas Gleixner wrote:
> On Thu, 18 Dec 2014, Jacob Pan wrote:
> > OK I agree, also as I mentioned earlier, Peter already has a patch
> > for consolidated idle loop and remove tick_nohz_idle_enter/exit
> > call from powerclamp driver
>
>
> -Original Message-
> From: Preeti U Murthy [mailto:pre...@linux.vnet.ibm.com]
> Sent: Thursday, December 18, 2014 9:28 AM
> To: Thomas Gleixner; Preeti Murthy; Pan, Jacob jun; Peter Zijlstra
> Cc: Viresh Kumar; Frederic Weisbecker; Wu, Fengguang; Frederic
> Weisbecker; LKML; LKP; Zh
701 - 800 of 980 matches
Mail list logo
