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
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 be too short or too long for it (respectively).
These met
13 matches
Mail list logo
