[PATCH 1/4] ktime: add a roundup function

ktime roundup function can be used to keep timer aligned and prevent drift for recurring timeouts. Signed-off-by: Jacob Pan <jacob.jun@linux.intel.com> --- include/linux/ktime.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/k

Re: [PATCH 1/4] ktime: add a roundup function

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

Re: [PATCH 2/4] timer: relax tick stop in idle entry

On Fri, 13 Nov 2015 15:22:16 -0500 (EST) Thomas Gleixner <t...@linutronix.de> 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

Re: [PATCH 1/4] ktime: add a roundup function

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

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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: > > >

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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(_inject_timer); > > + int cpu = smp_processor_id(); > > + ktime_t now, delta, period; > > + bool status;

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

On Tue, 10 Nov 2015 15:58:23 +0100 Peter Zijlstra <pet...@infradead.org> 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 <pet...@infradead.org> wrote: > >

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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 > >

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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 > >

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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(_inject_timer); > > + int cpu = smp_processor_id(); > > + ktime_t now, delta,

[RFC PATCH v2 1/3] ktime: add a roundup function

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

[RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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: Jacob Pan

[RFC PATCH v2 0/3] CFS idle injection

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 roundup

[RFC PATCH v2 2/3] timer: relax tick stop in idle entry

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

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 only

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 0/3] CFS idle injection

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. >

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 0/3] CFS idle injection

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 >

Re: [RFC PATCH 0/3] CFS idle injection

On Mon, 9 Nov 2015 15:15:34 +0100 Peter Zijlstra <pet...@infradead.org> wrote: > On Mon, Nov 09, 2015 at 11:56:51AM +, Punit Agrawal wrote: > > Jacob Pan <jacob.jun@linux.intel.com> writes: > > > My take is that RT and throttling will neve

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On Fri, 6 Nov 2015 15:49:29 -0800 Jacob Pan <jacob.jun@linux.intel.com> 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 ha

[RFC PATCH v2 1/3] ktime: add a roundup function

ktime roundup function can be used to keep timer aligned and prevent drift for recurring timeouts. Signed-off-by: Jacob Pan <jacob.jun@linux.intel.com> --- include/linux/ktime.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/k

[RFC PATCH v2 0/3] CFS idle injection

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 roundup

[RFC PATCH v2 3/3] sched: introduce synchronized idle injection

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: Jacob Pan

[RFC PATCH v2 2/3] timer: relax tick stop in idle entry

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 <jacob.

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH 0/3] CFS idle injection

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,

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On Fri, 6 Nov 2015 08:45:10 +0100 Peter Zijlstra <pet...@infradead.org> 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

Re: [RFC PATCH 0/3] CFS idle injection

On Fri, 6 Nov 2015 18:30:01 + Dietmar Eggemann <dietmar.eggem...@arm.com> 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: > >

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

if (!cfs_rq->runnable) > goto idle; > > put_prev_task(rq, prev); > @@ -5302,6 +5304,9 @@ simple: > return p; > > idle: > + if (cfs_rq->forced_idle) > + return NULL; > + > /* >* This is OK,

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 _||| || |___| || |___ &

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On Thu, 5 Nov 2015 11:09:22 +0100 Peter Zijlstra wrote: > > Before: > > CPU0 __||| || |___| || || |_ > > CPU1 _||| || |___| || |___ > > > > After: > > > > CPU0 __||| || |___| || || |_ > > CPU1 __||| || |___| || |___ > > > >

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On Thu, 5 Nov 2015 11:27:32 -0800 Jacob Pan <jacob.jun@linux.intel.com> wrote: > On Thu, 5 Nov 2015 11:09:22 +0100 > Peter Zijlstra <pet...@infradead.org> wrote: > > > > Before: > > > CPU0 __||| ||

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

On Thu, 5 Nov 2015 11:09:22 +0100 Peter Zijlstra wrote: > > Before: > > CPU0 __||| || |___| || || |_ > > CPU1 _||| || |___| || |___ > > > > After: > > > > CPU0 __||| || |___| || || |_ > > CPU1 __||| || |___|

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

* 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/

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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

Re: [RFC PATCH 0/3] CFS idle injection

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

Re: [RFC PATCH 0/3] CFS idle injection

On Tue, 3 Nov 2015 22:06:55 -0800 Eduardo Valentin <edubez...@gmail.com> 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 &g

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 && > > +

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 && > > +

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 &&

Re: [RFC PATCH 3/3] sched: introduce synchronized idle injection

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 &&

[RFC PATCH 0/3] CFS idle injection

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 roundup function timer: relax tick stop

[RFC PATCH 3/3] sched: introduce synchronized idle injection

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: Jacob Pan

[RFC PATCH 2/3] timer: relax tick stop in idle entry

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

[RFC PATCH 1/3] ktime: add a roundup function

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

[RFC PATCH 1/3] ktime: add a roundup function

ktime roundup function can be used to keep timer aligned and prevent drift for recurring timeouts. Signed-off-by: Jacob Pan <jacob.jun@linux.intel.com> --- include/linux/ktime.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/linux/ktime.h b/include/linux/k

[RFC PATCH 0/3] CFS idle injection

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 roundup function timer: relax tick stop

[RFC PATCH 3/3] sched: introduce synchronized idle injection

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: Jacob Pan

[RFC PATCH 2/3] timer: relax tick stop in idle entry

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 <jacob.

Re: [PATCH] tools/thermal: tmon: use pkg-config also for CFLAGS

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

Re: [PATCH] tools/thermal: tmon: use pkg-config also for CFLAGS

On Fri, 2 Oct 2015 09:50:45 + Olaf Hering <o...@aepfle.de> 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 <jacob.jun@linux.intel.com> thanks > Signe

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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 wrote: &

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

om** >> MOKOKWarn on Atom >> NOKOKOK >> ___ *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 +08

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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. >

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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,

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

On Tue, 22 Sep 2015 11:11:36 +0800 Pengyu Ma <pengyu...@windriver.com> wrote: > > > On 09/22/2015 05:36 AM, Jacob Pan wrote: > > On Mon, 21 Sep 2015 11:48:14 +0800 > > Pengyu Ma <pengyu...@windriver.com> wrote: > > > >> > >> On 09/18/201

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

On Tue, 22 Sep 2015 09:41:52 -0400 Austin S Hemmelgarn <ahferro...@gmail.com> wrote: > On 2015-09-21 17:36, Jacob Pan wrote: > > On Mon, 21 Sep 2015 11:48:14 +0800 > > Pengyu Ma <pengyu...@windriver.com> wrote: > > > >> > >> > >> On 09/

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

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:

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

On Mon, 21 Sep 2015 11:48:14 +0800 Pengyu Ma <pengyu...@windriver.com> wrote: > > > On 09/18/2015 11:43 PM, Jacob Pan wrote: > > On Fri, 18 Sep 2015 02:09:55 +0200 > > "Rafael J. Wysocki" <r...@rjwysocki.net> wrote: > > > >> O

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

l RAPL 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 from th

Re: [PATCH] powercap / RAPL : remove dependency on iosf_mbi

g INTEL_RAPL > > tristate "Intel RAPL Support" > > - depends on X86 && IOSF_MBI > > + depends on X86 > > default n > > ---help--- > > This enables support for the Intel Running Average Power > > Limit (RAPL) >

[PATCH] thermal/powerclamp: add cpu id for denlow platform

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

[PATCH] thermal/powerclamp: add cpu id for denlow platform

Add support for Intel Denlow UP server platform. Signed-off-by: Jacob Pan jacob.jun@linux.intel.com --- 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

Re: [PATCH v3] perf/rapl: support per domain energy unit

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

Re: [PATCH v3] perf/rapl: support per domain energy unit

On Mon, 15 Jun 2015 13:32:01 -0400 (EDT) Vince Weaver vincent.wea...@maine.edu 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 domains

Re: [PATCH] perf/x86/intel/rapl: Add support for Knights Landing (KNL)

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

Re: [PATCH] perf/x86/intel/rapl: Add support for Knights Landing (KNL)

On Tue, 26 May 2015 11:47:39 -0700 Dasaratharaman Chandramouli dasaratharaman.chandramo...@intel.com 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 jacob.jun

Re: [PATCH] powercap / RAPL: Support Knights Landing

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

Re: [PATCH] powercap / RAPL: Support Knights Landing

),/* Future Xeon */ RAPL_CPU(0x5A, rapl_defaults_atom),/* Annidale */ + RAPL_CPU(0x57, rapl_defaults_hsw_server),/* Knights Landing */ {} }; MODULE_DEVICE_TABLE(x86cpu, rapl_ids); [Jacob Pan] -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body

Re: [PATCH] tools/thermal: tmon: fixed the 'make install' command

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

[PATCH] thermal/powerclamp: fix missing newer package c-states

. 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

Re: [PATCH] tools/thermal: tmon: fixed the 'make install' command

On Fri, 8 May 2015 03:39:04 +0930 Anand Moon linux.am...@gmail.com 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 jacob.jun@linux.intel.com root@odroidxu3:/usr/src/odroidxu3

[PATCH] thermal/powerclamp: fix missing newer package c-states

. Reported-by: Kristen Carlson Accardi kris...@linux.intel.com Signed-off-by: Jacob Pan jacob.jun@linux.intel.com --- drivers/thermal/intel_powerclamp.c | 80 -- 1 file changed, 43 insertions(+), 37 deletions(-) diff --git a/drivers/thermal/intel_powerclamp.c b

Re: [PATCH] intel powerclamp: support Knights Landing

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

Re: [PATCH] intel powerclamp: support Knights Landing

On Fri, 24 Apr 2015 10:33:34 -0700 Dasaratharaman Chandramouli dasaratharaman.chandramo...@intel.com 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

[tip:perf/urgent] perf/x86/intel/rapl: Fix energy counter measurements but supporing per domain energy units

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

[tip:perf/urgent] perf/x86/intel/rapl: Fix energy counter measurements but supporing per domain energy units

Commit-ID: 645523960102fa0ac0578d070630e49ab05f06d1 Gitweb: http://git.kernel.org/tip/645523960102fa0ac0578d070630e49ab05f06d1 Author: Jacob Pan jacob.jun@linux.intel.com AuthorDate: Thu, 26 Mar 2015 14:28:45 -0700 Committer: Ingo Molnar mi...@kernel.org CommitDate: Fri, 17 Apr 2015

Re: [PATCH v3] perf/rapl: support per domain energy unit

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 lear

Re: [PATCH v3] perf/rapl: support per domain energy unit

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, > &

Re: [PATCH v3] perf/rapl: support per domain energy unit

On Mon, 6 Apr 2015 10:30:33 -0700 Stephane Eranian eran...@google.com wrote: On Mon, Apr 6, 2015 at 8:21 AM, Jacob Pan jacob.jun@linux.intel.com wrote: On Thu, 26 Mar 2015 14:28:45 -0700 Jacob Pan jacob.jun@linux.intel.com wrote: RAPL energy hardware unit can vary within

Re: [PATCH v3] perf/rapl: support per domain energy unit

On Wed, 15 Apr 2015 17:40:59 +0200 Peter Zijlstra pet...@infradead.org 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 learning

Re: [PATCH v2] iio/axp288_adc: add missing channel info mask

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 adds m

Re: [PATCH v2] iio/axp288_adc: add missing channel info mask

On Thu, 09 Apr 2015 14:18:49 +0100 Jonathan Cameron ji...@kernel.org 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 adds missing channel info masks for all

[PATCH] powercap/rapl: add id for broadwell server

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

[PATCH] thermal/intel_powerclamp: add id for broadwell server

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

[PATCH] thermal/intel_powerclamp: add id for broadwell server

Broadwell server has support for package C-states, idle injection works as expected on this platform. Signed-off-by: Jacob Pan jacob.jun@linux.intel.com --- drivers/thermal/intel_powerclamp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/thermal/intel_powerclamp.c b/drivers

[PATCH] powercap/rapl: add id for broadwell server

Validated RAPL functions on this platform. Add support to driver. Signed-off-by: Jacob Pan jacob.jun@linux.intel.com --- 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

Re: [PATCH] iio/axp288_adc: add missing channel info mask

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

[PATCH v2] iio/axp288_adc: add missing channel info mask

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 @@ -53

<    7   8   9   10   11   12   13   14   15   16   >