[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1338843134.28282.145.camel@twins>
Date: Mon, 04 Jun 2012 22:52:14 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Arun Sharma <asharma@...com>
Cc: Andrew Vagin <avagin@...nvz.org>,
Oleg Strikov <OSTRIKOV@...dia.com>,
Steven Rostedt <rostedt@...dmis.org>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] [PATCH 0/5] Teach perf tool to profile sleep times (V4)
On Mon, 2012-06-04 at 10:01 -0700, Arun Sharma wrote:
> On 6/4/12 5:40 AM, Peter Zijlstra wrote:
>
> > And as a result you need that hideous prev_state crap.
> >
> >
> > Would something like the below work?
> >
> > The one thing I'm not entirely sure of is if this is a sekjoerity issue
> > or not.. anybody? I would think a task was entitled to know who woke it
> > and wherefrom etc..
>
> Frederic had some comments on this topic in the last round:
>
> http://thread.gmane.org/gmane.linux.kernel/1195368/focus=1195959
>
> > We should probably avoid the remote callchains, sounds like asking
> for complications everywhere.
>
> Do they still apply? Frederic?
Probably, but note that the approaches are slightly different. The
previous thing would wreck the callchain for everybody, the proposed
thing will make more events.
Also, you don't need the callchain on the wakeup side of things. You
only want the callchain of the sched_switch site.
We could even dis-allow the callchain unwind when event->ctx->task &&
event->ctx->task != current -- pretend the unwind failed by writing 0
entries.
That also avoids the 'difficultly' of exposing and trying to interpret
another task's callchain.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists