On Monday, February 20, 2017 02:49:18 PM Rafael J. Wysocki wrote:
> On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote:
> > On 17-02-17, 13:48, Peter Zijlstra wrote:
> > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, February 16, 2017 01:36:05 PM
On Monday, February 20, 2017 02:49:18 PM Rafael J. Wysocki wrote:
> On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote:
> > On 17-02-17, 13:48, Peter Zijlstra wrote:
> > > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > > > On Thursday, February 16, 2017 01:36:05 PM
On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote:
> On 17-02-17, 13:48, Peter Zijlstra wrote:
> > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > > > On Thu, Feb 16, 2017 at 03:42:10PM +0530,
On Monday, February 20, 2017 03:28:03 PM Viresh Kumar wrote:
> On 17-02-17, 13:48, Peter Zijlstra wrote:
> > On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > > > On Thu, Feb 16, 2017 at 03:42:10PM +0530,
On 17-02-17, 13:48, Peter Zijlstra wrote:
> On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > > > But when I discussed this with Vincent, he
On 17-02-17, 13:48, Peter Zijlstra wrote:
> On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> > On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > > > But when I discussed this with Vincent, he
On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > > But when I discussed this with Vincent, he suggested that it may not be
> > > required
> >
On Fri, Feb 17, 2017 at 01:15:56PM +0100, Rafael J. Wysocki wrote:
> On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> > On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > > But when I discussed this with Vincent, he suggested that it may not be
> > > required
> >
On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > But when I discussed this with Vincent, he suggested that it may not be
> > required
> > at all as the scheduler (with the helped of "decayed") doesn't call into
>
On Thursday, February 16, 2017 01:36:05 PM Peter Zijlstra wrote:
> On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> > But when I discussed this with Vincent, he suggested that it may not be
> > required
> > at all as the scheduler (with the helped of "decayed") doesn't call into
>
On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> But when I discussed this with Vincent, he suggested that it may not be
> required
> at all as the scheduler (with the helped of "decayed") doesn't call into
> schedutil too often, i.e. at least 1 ms. And if the CPUs are stable
On Thu, Feb 16, 2017 at 03:42:10PM +0530, Viresh Kumar wrote:
> But when I discussed this with Vincent, he suggested that it may not be
> required
> at all as the scheduler (with the helped of "decayed") doesn't call into
> schedutil too often, i.e. at least 1 ms. And if the CPUs are stable
On 16-02-17, 01:02, Rafael J. Wysocki wrote:
> More precisely, while the governor computations are less costly than updating
> the CPU state, they are not zero-cost, so do we really want to run them on
> every governor callback invocation until the CPU state is updated?
>
> We may end up running
On 16-02-17, 01:02, Rafael J. Wysocki wrote:
> More precisely, while the governor computations are less costly than updating
> the CPU state, they are not zero-cost, so do we really want to run them on
> every governor callback invocation until the CPU state is updated?
>
> We may end up running
On 15-02-17, 23:35, Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
>
> First of all, [RFC] pretty please on things like this.
Sure.
> > Normally, the time it takes to reevaluate the frequency is negligible
> > compared to the time it takes to change
On 15-02-17, 23:35, Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
>
> First of all, [RFC] pretty please on things like this.
Sure.
> > Normally, the time it takes to reevaluate the frequency is negligible
> > compared to the time it takes to change
On Wednesday, February 15, 2017 11:52:49 PM Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 11:35:29 PM Rafael J. Wysocki wrote:
> > On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
> >
> > First of all, [RFC] pretty please on things like this.
> >
> > > For an ideal
On Wednesday, February 15, 2017 11:52:49 PM Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 11:35:29 PM Rafael J. Wysocki wrote:
> > On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
> >
> > First of all, [RFC] pretty please on things like this.
> >
> > > For an ideal
On Wednesday, February 15, 2017 11:35:29 PM Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
>
> First of all, [RFC] pretty please on things like this.
>
> > For an ideal system (where frequency change doesn't incur any penalty)
> > we would like to
On Wednesday, February 15, 2017 11:35:29 PM Rafael J. Wysocki wrote:
> On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
>
> First of all, [RFC] pretty please on things like this.
>
> > For an ideal system (where frequency change doesn't incur any penalty)
> > we would like to
On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
First of all, [RFC] pretty please on things like this.
> For an ideal system (where frequency change doesn't incur any penalty)
> we would like to change the frequency as soon as the load changes for a
> CPU. But the systems we have
On Wednesday, February 15, 2017 10:45:47 PM Viresh Kumar wrote:
First of all, [RFC] pretty please on things like this.
> For an ideal system (where frequency change doesn't incur any penalty)
> we would like to change the frequency as soon as the load changes for a
> CPU. But the systems we have
For an ideal system (where frequency change doesn't incur any penalty)
we would like to change the frequency as soon as the load changes for a
CPU. But the systems we have to work with are far from ideal and it
takes time to change the frequency of a CPU. For many ARM platforms
specially, it is at
For an ideal system (where frequency change doesn't incur any penalty)
we would like to change the frequency as soon as the load changes for a
CPU. But the systems we have to work with are far from ideal and it
takes time to change the frequency of a CPU. For many ARM platforms
specially, it is at
24 matches
Mail list logo