Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1286677
| From | Alexander Shishkin <alexander.shishkin@linux.intel.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 2/7] perf: Generalize task_function_call()ers |
| Date | 2015-12-08 17:50 +0100 |
| Message-ID | <qDtCF-4NA-7@gated-at.bofh.it> (permalink) |
| References | <qBzsR-3Jm-3@gated-at.bofh.it> <qBzsT-3Jm-35@gated-at.bofh.it> <qBG1k-8ar-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Peter Zijlstra <peterz@infradead.org> writes:
> OK, so the retry_state thing is clever, but either I'm too tired or its
> not quite right. Nor do I think its actually required.
>
> /me frobs...
>
> Hmm, I cannot seem to convince myself the current code is correct to
> begin with.
>
> In any case, consider the below (on top of my previous collapse patch).
> The two 'hard' cases are perf_event_{dis,en}able(), those appear to play
> silly games with event->state.
>
> So starting with perf_event_disable(); we don't strictly need to test
> for event->state == ACTIVE, ctx->is_active is enough. If the event is
> not scheduled while the ctx is, __perf_event_disable() still does the
> right thing. Its a little less efficient to IPI in that case, over-all
> simpler.
>
> For perf_event_enable(); the same goes, but I think that's actually
> broken in its current form. The current condition is: ctx->is_active &&
> event->state == OFF, that means it doesn't do anything when !ctx->active
> && event->state == OFF. This is wrong, it should still mark the event
> INACTIVE in that case, otherwise we'll still not try and schedule the
> event once the context becomes active again.
Yes, this does look more logically correct.
>
>
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -1766,6 +1766,20 @@ int __perf_event_disable(void *info)
> return 0;
> }
>
> +void ___perf_event_disable(void *info)
Only maybe change these to __perf_event_disable_locked() or something
visually distinctive from the 'active' callback?
FWIW,
Reviewed-by: Alexander Shishkin <alexander.shishkin@intel.com>
Thanks,
--
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 2/7] perf: Generalize task_function_call()ers Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-03 11:40 +0100
Re: [PATCH 2/7] perf: Generalize task_function_call()ers Peter Zijlstra <peterz@infradead.org> - 2015-12-03 18:40 +0100
Re: [PATCH 2/7] perf: Generalize task_function_call()ers Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2015-12-08 17:50 +0100
Re: [PATCH 2/7] perf: Generalize task_function_call()ers Peter Zijlstra <peterz@infradead.org> - 2015-12-08 18:00 +0100
csiph-web