On Thu, Feb 13, 2014 at 2:02 PM, Jiri Olsa wrote:
> On Tue, Feb 11, 2014 at 08:50:13AM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
>> > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
>> > > Assuming you can decode
On Tue, Feb 11, 2014 at 08:50:13AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
> > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > > Assuming you can decode and get the info about the base registers used,
> > > yo
On Tue, Feb 11, 2014 at 08:50:13AM -0300, Arnaldo Carvalho de Melo wrote:
> 3) PERF_SAMPLE_REGS_USER (from a quick look, why do we have "USER" in
> it? Jiri?)
Note that the regs are in the POST instruction state, so any op that
does something like:
MOV %edx, $(eax+edx*8)
Will have lost the ori
On Tue, Feb 11, 2014 at 12:31:49PM +0100, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 12:28:47PM +0100, Stephane Eranian wrote:
> > On Tue, Feb 11, 2014 at 12:14 PM, Peter Zijlstra
> > wrote:
> > > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > >> Assuming you can decod
Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
> On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > Assuming you can decode and get the info about the base registers used,
> > you'd have to do this for each arch with load/store sampling capabilities.
> > this
On Tue, Feb 11, 2014 at 12:28:47PM +0100, Stephane Eranian wrote:
> On Tue, Feb 11, 2014 at 12:14 PM, Peter Zijlstra wrote:
> > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> >> Assuming you can decode and get the info about the base registers used,
> >> you'd have to do this
On Tue, Feb 11, 2014 at 12:14 PM, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
>> Assuming you can decode and get the info about the base registers used,
>> you'd have to do this for each arch with load/store sampling capabilities.
>> this is painful co
On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> Assuming you can decode and get the info about the base registers used,
> you'd have to do this for each arch with load/store sampling capabilities.
> this is painful compared to getting the portable info from dwarf directly.
But
On Tue, Feb 11, 2014 at 12:04 PM, Stephane Eranian wrote:
> On Tue, Feb 11, 2014 at 12:02 PM, Peter Zijlstra wrote:
>> On Tue, Feb 11, 2014 at 11:58:45AM +0100, Stephane Eranian wrote:
>>> On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra
>>> wrote:
>>> > On Tue, Feb 11, 2014 at 11:35:45AM +0100
On Tue, Feb 11, 2014 at 12:04:23PM +0100, Stephane Eranian wrote:
> >> How do you know that load at addr 0x1000 is accessing variable bar?
> >> The IP gives you line number, and then what?
> >> I think dwarf has the mapping regs -> variable and yes, the type info.
> >> But I am not sure that's enou
On Tue, Feb 11, 2014 at 12:02 PM, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 11:58:45AM +0100, Stephane Eranian wrote:
>> On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra
>> wrote:
>> > On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
>> >> On Tue, Feb 11, 2014 at 8:14 AM,
On Tue, Feb 11, 2014 at 11:58:45AM +0100, Stephane Eranian wrote:
> On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra wrote:
> > On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
> >> On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra
> >> wrote:
> >> >
> >> > That blows; how much is
On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra wrote:
> On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
>> On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra wrote:
>> >
>> > That blows; how much is missing?
>>
>> They need to annotate load and stores. I asked for that feature a
On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
> On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra wrote:
> >
> > That blows; how much is missing?
>
> They need to annotate load and stores. I asked for that feature a while ago.
> It will come.
And there is no way to deduce the i
On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra wrote:
> On Mon, Feb 10, 2014 at 11:21:53PM +0100, Stephane Eranian wrote:
>> On Mon, Feb 10, 2014 at 10:29 PM, Peter Zijlstra
>> wrote:
>> > On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
>> >> The data output is verbose and there are
On Mon, Feb 10, 2014 at 11:21:53PM +0100, Stephane Eranian wrote:
> On Mon, Feb 10, 2014 at 10:29 PM, Peter Zijlstra wrote:
> > On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> >> The data output is verbose and there are lots of data tables that
> >> interprit the latencies
> >> and
On Mon, Feb 10, 2014 at 10:29 PM, Peter Zijlstra wrote:
> On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
>> The data output is verbose and there are lots of data tables that interprit
>> the latencies
>> and data addresses in different ways to help see where bottlenecks might be
>>
On Mon, Feb 10, 2014 at 10:29:55PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> > The data output is verbose and there are lots of data tables that interprit
> > the latencies
> > and data addresses in different ways to help see where bottlenecks mig
On Mon, Feb 10, 2014 at 10:18:25PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> > With the introduction of NUMA systems, came the possibility of remote
> > memory accesses.
> > Combine those remote memory accesses with contention on the remote node (
On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> The data output is verbose and there are lots of data tables that interprit
> the latencies
> and data addresses in different ways to help see where bottlenecks might be
> lying.
Would be good to see what the output looks like.
What
On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
> With the introduction of NUMA systems, came the possibility of remote memory
> accesses.
> Combine those remote memory accesses with contention on the remote node (ie a
> modified
> cacheline) and you have a possibility for very long l
On Mon, Feb 10, 2014 at 10:59:30AM -0800, Davidlohr Bueso wrote:
> This can be really useful for us performance folks, thanks. It seems
> however that the first two patches in the series are missing.
Odd, yes. For some reason they cc'd to me fine, just never made it to
lkml. Let me resend them.
This can be really useful for us performance folks, thanks. It seems
however that the first two patches in the series are missing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
With the introduction of NUMA systems, came the possibility of remote memory
accesses.
Combine those remote memory accesses with contention on the remote node (ie a
modified
cacheline) and you have a possibility for very long latencies. These latencies
can
bottleneck a program.
The program add
24 matches
Mail list logo
