On 22.08.2017 23:47, Peter Zijlstra wrote:
> On Thu, Aug 10, 2017 at 06:57:43PM +0300, Alexey Budankov wrote:
>> The key thing in the patch is explicit updating of tstamp fields for
>> INACTIVE events in update_event_times().
>
>> @@ -1405,6 +1426,9 @@ static void update_event_times(struct perf_ev
On Thu, Aug 10, 2017 at 06:57:43PM +0300, Alexey Budankov wrote:
> The key thing in the patch is explicit updating of tstamp fields for
> INACTIVE events in update_event_times().
> @@ -1405,6 +1426,9 @@ static void update_event_times(struct perf_event *event)
> event->group_leader->state
Well, Ok.
I re-implemented this patch of patch set and also implemented a unit
test that IMHO mimics the case mentioned above to check if it solves the issue.
The test is a single thread application that creates 272 fds for every of
two INSTRUCTIONS_RETIRED events covering 272 cores of Intel X
On 04.08.2017 15:51, Peter Zijlstra wrote:
> On Fri, Aug 04, 2017 at 02:35:34PM +0200, Peter Zijlstra wrote:
>> Something like:
>>
>> __update_state_and_time(event, new_state)
>> {
>> u64 delta, now = perf_event_time(event);
>> int old_state = event->state;
>>
>> event->tstamp = now;
On 04.08.2017 15:35, Peter Zijlstra wrote:
> On Thu, Aug 03, 2017 at 09:47:56PM +0300, Alexey Budankov wrote:
>> On 03.08.2017 18:00, Peter Zijlstra wrote:
>
>>> Are the magic spots, right? And I'm not convinced its right.
>>>
>>> Suppose I have two events in my context, and I created them 1 minut
On Fri, Aug 04, 2017 at 02:35:34PM +0200, Peter Zijlstra wrote:
> Something like:
>
> __update_state_and_time(event, new_state)
> {
> u64 delta, now = perf_event_time(event);
> int old_state = event->state;
>
> event->tstamp = now;
> event->state = new_state;
>
> d
On Thu, Aug 03, 2017 at 06:58:41PM +0300, Alexey Budankov wrote:
> On 03.08.2017 17:00, Peter Zijlstra wrote:
> > And I don't think I fully agree with your description of running.
>
> I copied this comment from the previous place without any change.
Ah, my bad, I often look at patches with all -
On Thu, Aug 03, 2017 at 09:47:56PM +0300, Alexey Budankov wrote:
> On 03.08.2017 18:00, Peter Zijlstra wrote:
> > Are the magic spots, right? And I'm not convinced its right.
> >
> > Suppose I have two events in my context, and I created them 1 minute
> > apart. Then their respective tstamp_enabl
On 03.08.2017 18:00, Peter Zijlstra wrote:
> On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote:
>> @@ -772,6 +780,10 @@ struct perf_event_context {
>> */
>> u64 time;
>> u64 timestamp;
>> +/*
>> + * Contex
On 03.08.2017 17:00, Peter Zijlstra wrote:
> On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote:
>> +struct perf_event_tstamp {
>> +/*
>> + * These are timestamps used for computing total_time_enabled
>> + * and total_time_running when the event is in INACTIVE or
>> + *
On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote:
> @@ -772,6 +780,10 @@ struct perf_event_context {
>*/
> u64 time;
> u64 timestamp;
> + /*
> + * Context cache for filtered out events;
> + */
>
On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote:
> +struct perf_event_tstamp {
> + /*
> + * These are timestamps used for computing total_time_enabled
> + * and total_time_running when the event is in INACTIVE or
> + * ACTIVE state, measured in nanoseconds from an
On Wed, Aug 02, 2017 at 11:15:39AM +0300, Alexey Budankov wrote:
> Event groups allocated for CPU's different from the one that handles
> multiplexing
> hrtimer interrupt may be skipped by interrupt handler however the events
> tstamp_enabled, tstamp_running and tstamp_stopped fields still need
13 matches
Mail list logo
