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,
> > >
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,
you'd have
On Thu, Feb 13, 2014 at 2:02 PM, Jiri Olsa jo...@redhat.com 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
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
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
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
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
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
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
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
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
On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org
wrote:
On Mon, Feb 10, 2014 at 12:28:55PM -0500, Don Zickus wrote:
The data
On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
On Tue, Feb 11, 2014 at 8:14 AM, Peter Zijlstra pet...@infradead.org 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
On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org wrote:
That blows; how much is missing?
They need to annotate load and stores.
On Tue, Feb 11, 2014 at 11:58:45AM +0100, Stephane Eranian wrote:
On Tue, Feb 11, 2014 at 11:52 AM, Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org
wrote:
On Tue, Feb 11, 2014 at 12:02 PM, Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org
wrote:
On Tue, Feb 11, 2014 at 11:35:45AM +0100, Stephane Eranian wrote:
On
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 enough.
Ah,
On Tue, Feb 11, 2014 at 12:04 PM, Stephane Eranian eran...@google.com wrote:
On Tue, Feb 11, 2014 at 12:02 PM, Peter Zijlstra pet...@infradead.org 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 pet...@infradead.org
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:14 PM, Peter Zijlstra pet...@infradead.org 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
On Tue, Feb 11, 2014 at 12:28:47PM +0100, Stephane Eranian wrote:
On Tue, Feb 11, 2014 at 12:14 PM, Peter Zijlstra pet...@infradead.org 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
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 is
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 pet...@infradead.org
wrote:
On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
Assuming you
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
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
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
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
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
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
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
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.
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
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 I
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 (ie
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 might be
On Mon, Feb 10, 2014 at 10:29 PM, Peter Zijlstra pet...@infradead.org 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
On Mon, Feb 10, 2014 at 11:21:53PM +0100, Stephane Eranian wrote:
On Mon, Feb 10, 2014 at 10:29 PM, Peter Zijlstra pet...@infradead.org 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
48 matches
Mail list logo
