[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1337856142.9783.104.camel@laptop>
Date: Thu, 24 May 2012 12:42:22 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Stephane Eranian <eranian@...gle.com>
Cc: Jiri Olsa <jolsa@...hat.com>, acme@...hat.com, mingo@...e.hu,
paulus@...ba.org, cjashfor@...ux.vnet.ibm.com, fweisbec@...il.com,
gorcunov@...nvz.org, tzanussi@...il.com, mhiramat@...hat.com,
robert.richter@....com, fche@...hat.com,
linux-kernel@...r.kernel.org, masami.hiramatsu.pt@...achi.com,
drepper@...il.com, asharma@...com, benjamin.redelings@...cent.org
Subject: Re: [PATCH 02/16] perf: Add ability to attach registers dump to
sample
On Thu, 2012-05-24 at 12:06 +0200, Stephane Eranian wrote:
> > What are we doing here and why?
> >
> I think this is related to a discusion we had earlier about which
> machine state you want
> to sample.
>
> There are 3 possible machine states:
> 1- user level (even when sample is in kernel AND assuming you did
> not hit a kernel only thread)
> 2- interrupted state (@ PMU interrupt)
> 3- precise state (state captured by PEBS on Intel, for instance)
>
> Jiri is only interested in 1/. I am interested in the other two as well.
>
> Question: is there a situation where we could need more than one machine
> state per sample?
Well, IIRC you always wanted both 2 and 3 at the same time to compute
skid, thus:
> If not, then a single bitmask is enough.
Indeed, so then we get to multiple bitmasks and unless you want to be
restricted to the same bitmap for all these types this setup won't
actually work.
Also, all that was missing from the changelog.
--
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