On Mon, Jan 14, 2019 at 11:39 AM Daniel Lezcano
wrote:
>
>
> Hi Rafael,
>
> sorry for the delay.
>
> On 10/01/2019 11:20, Rafael J. Wysocki wrote:
>
> [ ... ]
>
> >>> if (entered_state >= 0) {
> >>> + s64 diff, delay = drv->states[entered_state].exit_latency;
> >>> +
Hi Rafael,
sorry for the delay.
On 10/01/2019 11:20, Rafael J. Wysocki wrote:
[ ... ]
>>> if (entered_state >= 0) {
>>> + s64 diff, delay = drv->states[entered_state].exit_latency;
>>> + int i;
>>> +
>>> /*
>>>* Update cpuidle counte
On Thu, Jan 10, 2019 at 10:53 AM Daniel Lezcano
wrote:
>
> On 10/12/2018 12:30, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Add two new metrics for CPU idle states, "above" and "below", to count
> > the number of times the given state had been asked for (or entered
> > from the k
On 10/12/2018 12:30, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add two new metrics for CPU idle states, "above" and "below", to count
> the number of times the given state had been asked for (or entered
> from the kernel's perspective), but the observed idle duration turned
> out to
On Wed, Dec 12, 2018 at 10:57 AM Ulf Hansson wrote:
>
> On Wed, 12 Dec 2018 at 10:46, Peter Zijlstra wrote:
> >
> > On Tue, Dec 11, 2018 at 10:51:48AM +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra
> > > wrote:
> >
> > > > Dunno; it could be cold cacheline
On Wed, 12 Dec 2018 at 10:46, Peter Zijlstra wrote:
>
> On Tue, Dec 11, 2018 at 10:51:48AM +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra
> > wrote:
>
> > > Dunno; it could be cold cachelines, at which point it can be fairly
> > > expensive. Also, being stuck
On Tue, Dec 11, 2018 at 10:51:48AM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra wrote:
> > Dunno; it could be cold cachelines, at which point it can be fairly
> > expensive. Also, being stuck with API is fairly horrible if you want to
> > 'fix' it.
>
> All of
On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra wrote:
>
> On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
>
> > > One question on this; why is this tracked unconditionally?
> >
> > Because I didn't quite see how to make
On 2018.12.10 02:52 Peter Zijlstra wrote:
>On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote:
>> On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
>>> Would not a tracepoint be better?; then there is no overhead in the
>>> normal case where nobody gives a crap about these here
On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
> > One question on this; why is this tracked unconditionally?
>
> Because I didn't quite see how to make that conditional in a sensible way.
Something like:
if (s
On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
>
> On Mon, Dec 10, 2018 at 12:30:23PM +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Add two new metrics for CPU idle states, "above" and "below", to count
> > the number of times the given state had been asked for (or en
On Mon, Dec 10, 2018 at 12:30:23PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add two new metrics for CPU idle states, "above" and "below", to count
> the number of times the given state had been asked for (or entered
> from the kernel's perspective), but the observed idle dura
12 matches
Mail list logo