On Wed, Feb 04, 2015 at 05:33:36PM +0100, Peter Zijlstra wrote:
> On Wed, Feb 04, 2015 at 03:51:36PM +0100, Jiri Olsa wrote:
> > On Mon, Feb 02, 2015 at 06:32:32PM +0100, Peter Zijlstra wrote:
> > > > That looks like tail recursive fun! An irq work that raises and irq work
> > > > ad infinitum. Lem
On Wed, Feb 04, 2015 at 03:51:36PM +0100, Jiri Olsa wrote:
> On Mon, Feb 02, 2015 at 06:32:32PM +0100, Peter Zijlstra wrote:
> > > That looks like tail recursive fun! An irq work that raises and irq work
> > > ad infinitum. Lemme see if I can squash that.. didn't we have something
> > > like this b
On Mon, Feb 02, 2015 at 06:32:32PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 02, 2015 at 04:42:40PM +0100, Peter Zijlstra wrote:
> > On Mon, Feb 02, 2015 at 01:33:14AM -0500, Vince Weaver wrote:
> > > [407484.309136] [ cut here ]
>
> > > [407484.588602] <>[]
> > > pe
On Mon, Feb 02, 2015 at 04:42:40PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 02, 2015 at 01:33:14AM -0500, Vince Weaver wrote:
> > [407484.309136] [ cut here ]
> > [407484.588602] <>[]
> > perf_prepare_sample+0x2ec/0x3c0
> > [407484.597358] [] __perf_event_overflow+
On Mon, Feb 02, 2015 at 01:33:14AM -0500, Vince Weaver wrote:
> On Thu, 29 Jan 2015, Peter Zijlstra wrote:
>
> > That said, it does need to do that sibling first leaders later install
> > order too. So I've put the below on top.
>
> so I've lost track of exactly which patches I should be running
On Thu, 29 Jan 2015, Peter Zijlstra wrote:
> That said, it does need to do that sibling first leaders later install
> order too. So I've put the below on top.
so I've lost track of exactly which patches I should be running (do I need
to apply both of the additional patches?)
Meanwhile my haswel
On Mon, Jan 26, 2015 at 05:26:39PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 23, 2015 at 01:52:01PM +0100, Peter Zijlstra wrote:
> Jiri reported triggering that WARN_ON_ONCE over the weekend:
>
> event_sched_out.isra.79+0x2b9/0x2d0
> group_sched_out+0x69/0xc0
> ctx_sched_out+0x106/0x130
> tas
On Thu, Jan 29, 2015 at 08:51:26AM +0100, Jiri Olsa wrote:
> > [162118.235829] [ cut here ]
> > [162118.241388] WARNING: CPU: 5 PID: 13571 at kernel/events/core.c:1644
> > perf_remove_from_context+0xf5/0x120()
> > [162118.252183] Modules linked in: fuse x86_pkg_temp_thermal
On Wed, Jan 28, 2015 at 09:16:49PM -0500, Vince Weaver wrote:
> On Tue, 27 Jan 2015, Vince Weaver wrote:
>
> > On Mon, 26 Jan 2015, Peter Zijlstra wrote:
> >
> > > I think the below should cure this; if we install a group leader it will
> > > iterate the (still intact) group list and find its sib
On Tue, 27 Jan 2015, Vince Weaver wrote:
> On Mon, 26 Jan 2015, Peter Zijlstra wrote:
>
> > I think the below should cure this; if we install a group leader it will
> > iterate the (still intact) group list and find its siblings and try and
> > install those too -- even though those still have th
On Mon, 26 Jan 2015, Peter Zijlstra wrote:
> I think the below should cure this; if we install a group leader it will
> iterate the (still intact) group list and find its siblings and try and
> install those too -- even though those still have the old event->ctx --
> in the new ctx.
I've been fuz
On Fri, Jan 23, 2015 at 01:52:01PM +0100, Peter Zijlstra wrote:
> @@ -1442,6 +1450,10 @@ event_sched_out(struct perf_event *event
> {
> u64 tstamp = perf_event_time(event);
> u64 delta;
> +
> + WARN_ON_ONCE(event->ctx != ctx);
> + lockdep_assert_held(&ctx->lock);
> +
> /*
Add a few WARNs to catch things that should never happen.
Signed-off-by: Peter Zijlstra (Intel)
---
kernel/events/core.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -1275,6 +1275,8 @@ static void perf_group
13 matches
Mail list logo
