[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 3 Mar 2023 01:21:51 +0000
From: Song Liu <songliubraving@...a.com>
To: Namhyung Kim <namhyung@...nel.org>,
Peter Zijlstra <peterz@...radead.org>
CC: Song Liu <songliubraving@...a.com>, Song Liu <song@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Kernel Team <kernel-team@...a.com>
Subject: Re: [PATCH] perf: fix perf_event_context->time
> On Mar 2, 2023, at 1:15 PM, Namhyung Kim <namhyung@...nel.org> wrote:
>
> On Wed, Mar 1, 2023 at 3:16 PM Song Liu <songliubraving@...a.com> wrote:
>>
>>
>>
>>> On Mar 1, 2023, at 2:29 PM, Namhyung Kim <namhyung@...nel.org> wrote:
>>>
>>> Hi Song,
>>>
>>> On Tue, Feb 28, 2023 at 11:22 AM Song Liu <song@...nel.org> wrote:
>>>>
>>>> Time readers rely on perf_event_context->[time|timestamp|timeoffset] to get
>>>> accurate time_enabled and time_running for an event. The difference between
>>>> ctx->timestamp and ctx->time is the among of time when the context is not
>>>> enabled. For cpuctx.ctx, time and timestamp should stay the same, however,
>>>
>>> I'm not sure if it's correct. The timestamp can go when the context is disabled
>>> for example, in ctx_resched() even if the NMI watchdog is enabled, right?
>>
>> I think we do not disable EVENT_TIME for per cpu ctx?
>
> I can see ctx_sched_out(ctx, EVENT_TIME) in some places.
> Also it'd reset EVENT_TIME if both _PINNED and _FLEXIBLE is
> cleared.
Yeah, you are right. I missed this part.
Hi Peter,
Does this fix look good do you?
Thanks,
Song
Powered by blists - more mailing lists