On Tue, Mar 1, 2016 at 4:04 PM, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 02:42:10PM +, Juri Lelli wrote:
>> Agree. My point was actually more about Rafael's schedutil RFC (I should
>> probably have posted this there, but I thought it fitted well with this
>> example). I realize that Raf
On Tue, Mar 01, 2016 at 02:42:10PM +, Juri Lelli wrote:
> Agree. My point was actually more about Rafael's schedutil RFC (I should
> probably have posted this there, but I thought it fitted well with this
> example). I realize that Rafael is starting simple, but I fear that some
> aggregation o
On 1 March 2016 at 14:58, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
>
>> Another point to take into account is that the RT tasks will "steal"
>> the compute capacity that has been requested by the cfs tasks.
>>
>> Let takes the example of a CPU with 3
On 01/03/16 15:26, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 03:24:59PM +0100, Peter Zijlstra wrote:
> > On Tue, Mar 01, 2016 at 02:17:06PM +, Juri Lelli wrote:
> > > On 01/03/16 14:58, Peter Zijlstra wrote:
> > > > On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
> > > >
On Tue, Mar 01, 2016 at 03:24:59PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 01, 2016 at 02:17:06PM +, Juri Lelli wrote:
> > On 01/03/16 14:58, Peter Zijlstra wrote:
> > > On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
> > >
> > > > Another point to take into account is that
On Tue, Mar 01, 2016 at 02:17:06PM +, Juri Lelli wrote:
> On 01/03/16 14:58, Peter Zijlstra wrote:
> > On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
> >
> > > Another point to take into account is that the RT tasks will "steal"
> > > the compute capacity that has been reques
On 01/03/16 14:58, Peter Zijlstra wrote:
> On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
>
> > Another point to take into account is that the RT tasks will "steal"
> > the compute capacity that has been requested by the cfs tasks.
> >
> > Let takes the example of a CPU with 3 O
On Fri, Feb 12, 2016 at 03:48:54PM +0100, Vincent Guittot wrote:
> Another point to take into account is that the RT tasks will "steal"
> the compute capacity that has been requested by the cfs tasks.
>
> Let takes the example of a CPU with 3 OPP on which run 2 rt tasks A
> and B and 1 cfs task C
On Fri, Feb 12, 2016 at 6:02 PM, Doug Smythies wrote:
> On 2016.02.12 08:01 Rafael J. Wysocki wrote:
>> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
>>> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>> My concern abo
On Fri, Feb 12, 2016 at 5:53 PM, Ashwin Chaugule
wrote:
> On 12 February 2016 at 11:15, Rafael J. Wysocki wrote:
>> On Fri, Feb 12, 2016 at 5:01 PM, Rafael J. Wysocki wrote:
>>> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra
>>> wrote:
On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muck
On 2016.02.12 08:01 Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
>> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
>>> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
> My concern above is that pokes are guaranteed to keep occurring when
>
On 12 February 2016 at 11:15, Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 5:01 PM, Rafael J. Wysocki wrote:
>> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
>>> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>
On Fri, Feb 12, 2016 at 5:01 PM, Rafael J. Wysocki wrote:
> On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
>> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
>>> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>>> >> My concern above is that pokes are guaranteed to keep occurr
On Fri, Feb 12, 2016 at 3:10 PM, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
>> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>> >> My concern above is that pokes are guaranteed to keep occurring when
>> >> > there is only RT or DL activity so nothing brea
On 12 February 2016 at 15:04, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 07:23:55PM +0100, Vincent Guittot wrote:
>> I agree that using rt_avg is not the best choice to evaluate the
>> capacity that is used by RT tasks but it has the advantage of been
>> already there. Do you mean that we sho
On Thu, Feb 11, 2016 at 10:52:20AM -0800, Steve Muckle wrote:
> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
> >> My concern above is that pokes are guaranteed to keep occurring when
> >> > there is only RT or DL activity so nothing breaks.
> >
> > The hook in their respective tick handler should
On Thu, Feb 11, 2016 at 07:23:55PM +0100, Vincent Guittot wrote:
> I agree that using rt_avg is not the best choice to evaluate the
> capacity that is used by RT tasks but it has the advantage of been
> already there. Do you mean that we should use another way to compute
> the capacity that is used
On Thu, Feb 11, 2016 at 8:04 PM, Rafael J. Wysocki wrote:
> On Thu, Feb 11, 2016 at 7:52 PM, Steve Muckle wrote:
>> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
My concern above is that pokes are guaranteed to keep occurring when
> there is only RT or DL activity so nothing breaks.
>>>
On Thu, Feb 11, 2016 at 1:08 PM, Rafael J. Wysocki wrote:
> On Thu, Feb 11, 2016 at 12:51 PM, Peter Zijlstra wrote:
>> On Tue, Feb 09, 2016 at 09:05:05PM +0100, Rafael J. Wysocki wrote:
>>> > > One concern I had was, given that the lone scheduler update hook is in
>>> > > CFS, is it possible for
On Thu, Feb 11, 2016 at 7:52 PM, Steve Muckle wrote:
> On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>>> My concern above is that pokes are guaranteed to keep occurring when
>>> > there is only RT or DL activity so nothing breaks.
>>
>> The hook in their respective tick handler should ensure stuff
On 02/11/2016 09:30 AM, Peter Zijlstra wrote:
>> My concern above is that pokes are guaranteed to keep occurring when
>> > there is only RT or DL activity so nothing breaks.
>
> The hook in their respective tick handler should ensure stuff is called
> sporadically and isn't stalled.
But that's onl
On 11 February 2016 at 16:26, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 12:24:29PM +, Juri Lelli wrote:
>> Hi Peter,
>>
>> On 11/02/16 12:59, Peter Zijlstra wrote:
>> >
>> > No, for RT (RR/FIFO) we do not have enough information to do anything
>> > useful. Basically RR/FIFO should result
On Thu, Feb 11, 2016 at 06:34:05PM +0100, Rafael J. Wysocki wrote:
> I've updated the patch in the meantime
> (https://patchwork.kernel.org/patch/8283431/).
>
> Should I move the RT/DL hooks to task_tick_rt/dl(), respectively?
Probably, this really is about kicking cpufreq to do something, right?
On Thu, Feb 11, 2016 at 6:30 PM, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 09:06:04AM -0800, Steve Muckle wrote:
>> Hi Peter,
>>
>> >> > I think additional hooks such as enqueue/dequeue would be needed in
>> >> > RT/DL.
>
> That is what I reacted to mostly. Enqueue/dequeue hooks don't really
On Thu, Feb 11, 2016 at 09:06:04AM -0800, Steve Muckle wrote:
> Hi Peter,
>
> >> > I think additional hooks such as enqueue/dequeue would be needed in
> >> > RT/DL.
That is what I reacted to mostly. Enqueue/dequeue hooks don't really
make much sense for RT / DL.
> Rafael's changes aren't specify
Hi Peter,
On 02/11/2016 03:59 AM, Peter Zijlstra wrote:
>> I think additional hooks such as enqueue/dequeue would be needed in
>> > RT/DL. The task tick callbacks will only run if a task in that class is
>> > executing at the time of the tick. There could be intermittent RT/DL
>> > task activity i
On Thu, Feb 11, 2016 at 4:29 PM, Peter Zijlstra wrote:
> On Thu, Feb 11, 2016 at 01:08:28PM +0100, Rafael J. Wysocki wrote:
>> > Not really pretty though. It blows a bit that you require this callback
>> > to be periodic (in order to replace a timer).
>>
>> We need it for now, but that's because o
On Thu, Feb 11, 2016 at 01:08:28PM +0100, Rafael J. Wysocki wrote:
> > Not really pretty though. It blows a bit that you require this callback
> > to be periodic (in order to replace a timer).
>
> We need it for now, but that's because of how things work on the cpufreq side.
Right, maybe stick a
On Thu, Feb 11, 2016 at 12:24:29PM +, Juri Lelli wrote:
> Hi Peter,
>
> On 11/02/16 12:59, Peter Zijlstra wrote:
> > On Tue, Feb 09, 2016 at 05:02:33PM -0800, Steve Muckle wrote:
> > > > Index: linux-pm/kernel/sched/deadline.c
> > > > ===
Hi Peter,
On 11/02/16 12:59, Peter Zijlstra wrote:
> On Tue, Feb 09, 2016 at 05:02:33PM -0800, Steve Muckle wrote:
> > > Index: linux-pm/kernel/sched/deadline.c
> > > ===
> > > --- linux-pm.orig/kernel/sched/deadline.c
> > > +++ linux
On Thu, Feb 11, 2016 at 12:51 PM, Peter Zijlstra wrote:
> On Tue, Feb 09, 2016 at 09:05:05PM +0100, Rafael J. Wysocki wrote:
>> > > One concern I had was, given that the lone scheduler update hook is in
>> > > CFS, is it possible for governor updates to be stalled due to RT or DL
>> > > task activ
On Tue, Feb 09, 2016 at 05:02:33PM -0800, Steve Muckle wrote:
> > Index: linux-pm/kernel/sched/deadline.c
> > ===
> > --- linux-pm.orig/kernel/sched/deadline.c
> > +++ linux-pm/kernel/sched/deadline.c
> > @@ -1197,6 +1197,9 @@ static v
On Tue, Feb 09, 2016 at 09:05:05PM +0100, Rafael J. Wysocki wrote:
> > > One concern I had was, given that the lone scheduler update hook is in
> > > CFS, is it possible for governor updates to be stalled due to RT or DL
> > > task activity?
> >
> > I don't think they may be completely stalled, bu
On Wed, Feb 10, 2016 at 11:07 PM, Steve Muckle wrote:
> On 02/10/2016 01:49 PM, Rafael J. Wysocki wrote:
If done this way, I guess we may pass rq_clock_task(rq) as the time
>> arg to cpufreq_update_util() from there and then the cpu_lock() call
>> I've added to this prototype won't
On 02/10/2016 01:49 PM, Rafael J. Wysocki wrote:
>>> If done this way, I guess we may pass rq_clock_task(rq) as the time
>>> >> arg to cpufreq_update_util() from there and then the cpu_lock() call
>>> >> I've added to this prototype won't be necessary any more.
>> >
>> > Is it rq_clock_task() or rq
On Wed, Feb 10, 2016 at 8:47 PM, Steve Muckle wrote:
> On 02/09/2016 07:09 PM, Rafael J. Wysocki wrote:
>> I think additional hooks such as enqueue/dequeue would be needed in
>> RT/DL. The task tick callbacks will only run if a task in that class is
>> executing at the time of the t
On 02/09/2016 07:09 PM, Rafael J. Wysocki wrote:
>>> >> I think additional hooks such as enqueue/dequeue would be needed in
>>> >> RT/DL. The task tick callbacks will only run if a task in that class is
>>> >> executing at the time of the tick. There could be intermittent RT/DL
>>> >> task activity
On 10/02/16 16:46, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 3:46 PM, Juri Lelli wrote:
> > On 10/02/16 15:26, Rafael J. Wysocki wrote:
> >> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
> >> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
> >> >> On Wed, Feb 10, 2016 at 1:33 PM, Juri
On Wed, Feb 10, 2016 at 3:46 PM, Juri Lelli wrote:
> On 10/02/16 15:26, Rafael J. Wysocki wrote:
>> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
>> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
>> >> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
>> >> > Hi Rafael,
>> >> >
>> >> > On 0
On 10/02/16 15:26, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
> > On 10/02/16 14:23, Rafael J. Wysocki wrote:
> >> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
> >> > Hi Rafael,
> >> >
> >> > On 09/02/16 21:05, Rafael J. Wysocki wrote:
> >> >
> >> > [...]
On Wed, Feb 10, 2016 at 3:03 PM, Juri Lelli wrote:
> On 10/02/16 14:23, Rafael J. Wysocki wrote:
>> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
>> > Hi Rafael,
>> >
>> > On 09/02/16 21:05, Rafael J. Wysocki wrote:
>> >
>> > [...]
>> >
>> >> +/**
>> >> + * cpufreq_update_util - Take a note
On 10/02/16 14:23, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
> > Hi Rafael,
> >
> > On 09/02/16 21:05, Rafael J. Wysocki wrote:
> >
> > [...]
> >
> >> +/**
> >> + * cpufreq_update_util - Take a note about CPU utilization changes.
> >> + * @util: Current utilizat
On Wed, Feb 10, 2016 at 1:33 PM, Juri Lelli wrote:
> Hi Rafael,
>
> On 09/02/16 21:05, Rafael J. Wysocki wrote:
>
> [...]
>
>> +/**
>> + * cpufreq_update_util - Take a note about CPU utilization changes.
>> + * @util: Current utilization.
>> + * @max: Utilization ceiling.
>> + *
>> + * This functi
Hi Rafael,
On 09/02/16 21:05, Rafael J. Wysocki wrote:
[...]
> +/**
> + * cpufreq_update_util - Take a note about CPU utilization changes.
> + * @util: Current utilization.
> + * @max: Utilization ceiling.
> + *
> + * This function is called by the scheduler on every invocation of
> + * update_l
On Wed, Feb 10, 2016 at 2:57 AM, Rafael J. Wysocki wrote:
> On Wed, Feb 10, 2016 at 2:02 AM, Steve Muckle wrote:
>> On 02/09/2016 12:05 PM, Rafael J. Wysocki wrote:
> One concern I had was, given that the lone scheduler update hook is in
> CFS, is it possible for governor updates to be st
On Wed, Feb 10, 2016 at 2:02 AM, Steve Muckle wrote:
> On 02/09/2016 12:05 PM, Rafael J. Wysocki wrote:
One concern I had was, given that the lone scheduler update hook is in
CFS, is it possible for governor updates to be stalled due to RT or DL
task activity?
>>>
>>> I don't think
On 02/09/2016 12:05 PM, Rafael J. Wysocki wrote:
>>> One concern I had was, given that the lone scheduler update hook is in
>>> CFS, is it possible for governor updates to be stalled due to RT or DL
>>> task activity?
>>
>> I don't think they may be completely stalled, but I'd prefer Peter to
>> an
On Tuesday, February 09, 2016 02:01:39 AM Rafael J. Wysocki wrote:
> On Tue, Feb 9, 2016 at 1:39 AM, Steve Muckle wrote:
> > Hi Rafael,
> >
> > On 02/08/2016 03:06 PM, Rafael J. Wysocki wrote:
> >> Now that all review comments have been addressed in patch [3/3], I'm going
> >> to
> >> put this se
On Tue, Feb 9, 2016 at 1:39 AM, Steve Muckle wrote:
> Hi Rafael,
>
> On 02/08/2016 03:06 PM, Rafael J. Wysocki wrote:
>> Now that all review comments have been addressed in patch [3/3], I'm going to
>> put this series into linux-next.
>>
>> There already is 20+ patches on top of it in the queue in
Hi Rafael,
On 02/08/2016 03:06 PM, Rafael J. Wysocki wrote:
> Now that all review comments have been addressed in patch [3/3], I'm going to
> put this series into linux-next.
>
> There already is 20+ patches on top of it in the queue including fixes for
> bugs that have haunted us for quite some
On Wednesday, February 03, 2016 11:20:19 PM Rafael J. Wysocki wrote:
> On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
> > Hi,
> >
> > The following patch series introduces a mechanism allowing the cpufreq core
> > and "setpolicy" drivers to provide utilization update callbacks to
On Thu, Feb 4, 2016 at 11:51 AM, Juri Lelli wrote:
> Hi Rafael,
>
> On 03/02/16 23:20, Rafael J. Wysocki wrote:
>> On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > The following patch series introduces a mechanism allowing the cpufreq core
>> > and "setpolicy" dr
On Thu, Feb 4, 2016 at 1:08 AM, Srinivas Pandruvada
wrote:
>
>
> On 02/03/2016 02:20 PM, Rafael J. Wysocki wrote:
>>
>> On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
>>>
>>> Hi,
>>>
>>> The following patch series introduces a mechanism allowing the cpufreq
>>> core
>>> and "setp
Hi Rafael,
On 03/02/16 23:20, Rafael J. Wysocki wrote:
> On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
> > Hi,
> >
> > The following patch series introduces a mechanism allowing the cpufreq core
> > and "setpolicy" drivers to provide utilization update callbacks to be
> > invo
On 02/03/2016 02:20 PM, Rafael J. Wysocki wrote:
On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
Hi,
The following patch series introduces a mechanism allowing the cpufreq core
and "setpolicy" drivers to provide utilization update callbacks to be invoked
by the scheduler on u
On Friday, January 29, 2016 11:52:15 PM Rafael J. Wysocki wrote:
> Hi,
>
> The following patch series introduces a mechanism allowing the cpufreq core
> and "setpolicy" drivers to provide utilization update callbacks to be invoked
> by the scheduler on utilization changes. Those callbacks can be
Hi,
The following patch series introduces a mechanism allowing the cpufreq core
and "setpolicy" drivers to provide utilization update callbacks to be invoked
by the scheduler on utilization changes. Those callbacks can be used to run
the sampling and frequency adjustments code (intel_pstate) or t
57 matches
Mail list logo
