On 11/10/15, Peter Zijlstra wrote:
> On Tue, Nov 10, 2015 at 10:07:35AM +, Juri Lelli wrote:
> > Do you think that using SCHED_DEADLINE here would be completely
> > foolish? I mean, we would have the duty_cycle/period thing for free, it
> > would be know to the scheduler (as to maybe address Th
On Tue, Nov 10, 2015 at 10:07:35AM +, Juri Lelli wrote:
> Do you think that using SCHED_DEADLINE here would be completely
> foolish? I mean, we would have the duty_cycle/period thing for free, it
> would be know to the scheduler (as to maybe address Thomas' concerns)
> and we could think to mak
Hi,
On 9 November 2015 at 14:15, 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.
>>
>> I am not sure I follow. If RT (or ot
On Mon, Nov 09, 2015 at 01:23:04PM -0800, Jacob Pan wrote:
> what is WFI?
Wait For Interrupt; very like the x86 HLT thing.
> For Intel, idle states are hints to the HW. The FW decides how far the
> idle can go based on many factors, device states included, some are
> visible to the OS some are no
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.
> >
> > I am not sure I follow. If RT
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 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.
>
> I am not sure I follow. If RT (or other higher priority classes) can't
> be throttled then the CPUs
Jacob Pan writes:
> 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
On 11/06/2015 07:10 PM, Jacob Pan wrote:
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 now that it is not limited to a
sp
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 now that it is not limited to a
> >>> specific platf
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 now that it is not limited to a specific
>>> platform. One question though, could you still keep the cooling device
>>> suppor
Peter Zijlstra writes:
> People, trim your emails!
>
> On Wed, Nov 04, 2015 at 08:58:30AM -0800, Jacob Pan wrote:
>
>> > I also like #2 too. Specially now that it is not limited to a specific
>> > platform. One question though, could you still keep the cooling device
>> > support of it? In some s
People, trim your emails!
On Wed, Nov 04, 2015 at 08:58:30AM -0800, Jacob Pan wrote:
> > I also like #2 too. Specially now that it is not limited to a specific
> > platform. One question though, could you still keep the cooling device
> > support of it? In some systems, it might make sense to en
Hello Jacob, Srinivas,
On Wed, Nov 04, 2015 at 09:05:52AM -0800, Srinivas Pandruvada wrote:
> On Wed, 2015-11-04 at 08:58 -0800, Jacob Pan wrote:
> > > > I have two choices for this code:
> > > > 1) be part of existing powerclamp driver but require exporting some
> > > >sched APIs.
> > > > 2
On Wed, 2015-11-04 at 08:58 -0800, Jacob Pan wrote:
> 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 brok
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 off idle ticks in the forced idle perio
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 off idle ticks in the forced idle period.
> https://lkml.org/lkml/2014/12/18/369
>
> It was suggested to replace
Hi Peter and all,
A while ago, we had discussion about how powerclamp is broken in the
sense of turning off idle ticks in the forced idle period.
https://lkml.org/lkml/2014/12/18/369
It was suggested to replace the current kthread play idle loop with a
timer based runqueue throttling scheme. I fi
20 matches
Mail list logo
