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, Nov 10, 2015 at 08:50:55AM -0800, Jacob Pan wrote: > 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

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, Nov 10, 2015 at 08:28:59AM -0800, Jacob Pan wrote: > 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

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: > > > > > > hrtimer_forward(hrt, period); > > > > > >

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

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: > > > > hrtimer_forward(hrt, period); > > > > unconditionally. > In the ideal world yes. But my thinking was that timers may not be

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 Mon, Nov 09, 2015 at 04:21:23PM -0800, Jacob Pan wrote: > +++ b/include/trace/events/sched.h > +/* > + * Tracepoint for idle injection > + */ > +TRACE_EVENT(sched_cfs_idle_inject, > + > + TP_PROTO(char *msg, int throttled), > + > + TP_ARGS(msg, throttled), > + > + TP_STRUCT__entry(

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 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, Nov 10, 2015 at 08:50:55AM -0800, Jacob Pan wrote: > 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. > > >

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

On Tue, Nov 10, 2015 at 08:28:59AM -0800, Jacob Pan wrote: > 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

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

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: > > > > hrtimer_forward(hrt, period); > > > > unconditionally. > In the ideal world yes. But my thinking was

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 Mon, Nov 09, 2015 at 04:21:23PM -0800, Jacob Pan wrote: > +++ b/include/trace/events/sched.h > +/* > + * Tracepoint for idle injection > + */ > +TRACE_EVENT(sched_cfs_idle_inject, > + > + TP_PROTO(char *msg, int throttled), > + > + TP_ARGS(msg, throttled), > + > + TP_STRUCT__entry(

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 3/3] sched: introduce synchronized idle injection

With increasingly constrained power and thermal budget, it's often necessary to cap power via throttling. Throttling individual CPUs or devices at random times can help power capping but may not be optimal in terms of energy efficiency. In general, the optimal solution in terms of energy

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

With increasingly constrained power and thermal budget, it's often necessary to cap power via throttling. Throttling individual CPUs or devices at random times can help power capping but may not be optimal in terms of energy efficiency. In general, the optimal solution in terms of energy