| commit | e922e3380b4b02babff5feade9b1428945429a69 | |
| author | Peter Zijlstra <a.p.zijlstra@chello.nl> | |
| Tue, 15 Feb 2011 21:26:07 +0000 (15 22:26 +0100) | ||
| committer | Greg Kroah-Hartman <gregkh@suse.de> | |
| Thu, 24 Feb 2011 22:54:40 +0000 (24 14:54 -0800) | ||
| tree | 9841d7e295a6c5f7cea3a8f3031f70b79ff47147 | treesnapshot (tar.gz zip) |
| parent | d68e33163fe5801ce882824968fd4ec261d47af0 | commitdiff |
perf: Fix throttle logic
commit 4fe757dd48a9e95e1a071291f15dda5421dacb66 upstream.
It was possible to call pmu::start() on an already running event. In
particular this lead so some wreckage as the hrtimer events would
re-initialize active timers.
This was due to throttled events being activated again by scheduling.
Scheduling in a context would add and force start events, resulting in
running events with a possible throttle status. The next tick to hit
that task will then try to unthrottle the event and call ->start() on
an already running event.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit 4fe757dd48a9e95e1a071291f15dda5421dacb66 upstream.
It was possible to call pmu::start() on an already running event. In
particular this lead so some wreckage as the hrtimer events would
re-initialize active timers.
This was due to throttled events being activated again by scheduling.
Scheduling in a context would add and force start events, resulting in
running events with a possible throttle status. The next tick to hit
that task will then try to unthrottle the event and call ->start() on
an already running event.
Reported-by: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <new-submission>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| kernel/perf_event.c | diffblobblamehistory |