On Tue, Jul 30, 2013 at 06:09:15PM +0200, Stephane Eranian wrote:
> On Tue, Jul 30, 2013 at 5:52 PM, Peter Zijlstra wrote:
> > On Tue, Jul 30, 2013 at 04:21:41PM +0200, Stephane Eranian wrote:
> >> Peter,
> >>
> >> One thing that bothers me with the MMAP2 approach is that
> >> it forces integratio
On Tue, Jul 30, 2013 at 5:52 PM, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 04:21:41PM +0200, Stephane Eranian wrote:
>> Peter,
>>
>> One thing that bothers me with the MMAP2 approach is that
>> it forces integration into perf.
>
> This is a good (TM) thing, yes? ;-)
>
Well, that's one way t
On Tue, Jul 30, 2013 at 04:21:41PM +0200, Stephane Eranian wrote:
> Peter,
>
> One thing that bothers me with the MMAP2 approach is that
> it forces integration into perf.
This is a good (TM) thing, yes? ;-)
> Now, you will need to analyze
> the MMAP2 records. With my sample_type approach, you
>
On 7/30/13 8:53 AM, Stephane Eranian wrote:
On Tue, Jul 30, 2013 at 4:50 PM, David Ahern wrote:
On 7/30/13 8:21 AM, Stephane Eranian wrote:
One thing that bothers me with the MMAP2 approach is that
it forces integration into perf. Now, you will need to analyze
the MMAP2 records. With my sampl
On Tue, Jul 30, 2013 at 4:50 PM, David Ahern wrote:
> On 7/30/13 8:21 AM, Stephane Eranian wrote:
>>
>> One thing that bothers me with the MMAP2 approach is that
>> it forces integration into perf. Now, you will need to analyze
>> the MMAP2 records. With my sample_type approach, you
>> simply need
On 7/30/13 8:21 AM, Stephane Eranian wrote:
One thing that bothers me with the MMAP2 approach is that
it forces integration into perf. Now, you will need to analyze
the MMAP2 records. With my sample_type approach, you
simply needed a cmdline option on perf record, and then
you could dump the samp
Peter,
One thing that bothers me with the MMAP2 approach is that
it forces integration into perf. Now, you will need to analyze
the MMAP2 records. With my sample_type approach, you
simply needed a cmdline option on perf record, and then
you could dump the sample using perf report -D and feed
them
On Tue, Jul 30, 2013 at 11:02 AM, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 10:51:46AM +0200, Stephane Eranian wrote:
>> On Tue, Jul 30, 2013 at 10:37 AM, Peter Zijlstra
>> wrote:
>> > On Tue, Jul 30, 2013 at 10:02:01AM +0200, Stephane Eranian wrote:
>> >> > Ahh. We don't put the useful bi
On Tue, Jul 30, 2013 at 10:51:46AM +0200, Stephane Eranian wrote:
> On Tue, Jul 30, 2013 at 10:37 AM, Peter Zijlstra wrote:
> > On Tue, Jul 30, 2013 at 10:02:01AM +0200, Stephane Eranian wrote:
> >> > Ahh. We don't put the useful bits in the mmap event; we'll need to fix
> >> > that too then ;-)
>
On Tue, Jul 30, 2013 at 10:37 AM, Peter Zijlstra wrote:
> On Tue, Jul 30, 2013 at 10:02:01AM +0200, Stephane Eranian wrote:
>> > Ahh. We don't put the useful bits in the mmap event; we'll need to fix
>> > that too then ;-)
>> >
>> > Doing so is going to be a bit of a bother since we use the tail o
On Tue, Jul 30, 2013 at 10:02:01AM +0200, Stephane Eranian wrote:
> > Ahh. We don't put the useful bits in the mmap event; we'll need to fix
> > that too then ;-)
> >
> > Doing so is going to be a bit of a bother since we use the tail of
> > PERF_RECORD_MMAP for filenames and thus aren't particular
On Mon, Jul 8, 2013 at 10:19 AM, Peter Zijlstra wrote:
> On Sat, Jul 06, 2013 at 12:48:48AM +0200, Stephane Eranian wrote:
>> So, I tried on an example using shmat(). I map the same shared segment twice
>> in the same process. Then I fork(): I see this in /proc/PID/maps:
>>
>> 7f80fce28000-7f80fc
On Mon, Jul 8, 2013 at 10:19 AM, Peter Zijlstra wrote:
> On Sat, Jul 06, 2013 at 12:48:48AM +0200, Stephane Eranian wrote:
>> So, I tried on an example using shmat(). I map the same shared segment twice
>> in the same process. Then I fork(): I see this in /proc/PID/maps:
>>
>> 7f80fce28000-7f80fc
On Sat, Jul 06, 2013 at 12:48:48AM +0200, Stephane Eranian wrote:
> So, I tried on an example using shmat(). I map the same shared segment twice
> in the same process. Then I fork(): I see this in /proc/PID/maps:
>
> 7f80fce28000-7f80fce29000 rw-s 00:04 1376262
> /SYSV (deleted
Peter,
On Fri, Jun 28, 2013 at 11:58 AM, Peter Zijlstra wrote:
> On Wed, Jun 26, 2013 at 09:10:50PM +0200, Stephane Eranian wrote:
>> After more investigation with the author of the false sharing
>> detection tool, I think
>> that if the mapping changes, it is okay. The tool can detect this and
>
On Wed, Jun 26, 2013 at 09:10:50PM +0200, Stephane Eranian wrote:
> After more investigation with the author of the false sharing
> detection tool, I think
> that if the mapping changes, it is okay. The tool can detect this and
> drop the analysis
> at that address. So as long as we can flag the ma
On Wed, Jun 26, 2013 at 12:33 PM, Peter Zijlstra wrote:
> On Tue, Jun 25, 2013 at 12:51:23PM +0200, Ingo Molnar wrote:
>> A syscall (ioctl?) to dump all current vmas into the mmap update stream
>> (to form a starting point) might be handy - that would remove the
>> fragility and overhead of parsin
On Tue, Jun 25, 2013 at 12:51:23PM +0200, Ingo Molnar wrote:
> A syscall (ioctl?) to dump all current vmas into the mmap update stream
> (to form a starting point) might be handy - that would remove the
> fragility and overhead of parsing /proc/ details.
Its more difficult than that though :/ Su
* Peter Zijlstra wrote:
> > > Such would completely shatter physical page relations.
> > >
> > > If the shared memory thing is really the issue, doesn't perf already
> > > have the process memory layout (/proc/$PID/maps and aux stream mmap
> > > updates) with which it can compute map relative of
* Peter Zijlstra wrote:
> On Tue, Jun 25, 2013 at 11:59:09AM +0200, Stephane Eranian wrote:
> > One guarantee we have is that the physical does correspond to the virtual
> > address at the time of the interrupt.
>
> That might not be much of a guarantee depending on the circumstances.
>
> > Bu
On Tue, Jun 25, 2013 at 11:59:09AM +0200, Stephane Eranian wrote:
> One guarantee we have is that the physical does correspond to the virtual
> address at the time of the interrupt.
That might not be much of a guarantee depending on the circumstances.
> But yeah, if physical pages are swapped dur
On Mon, Jun 24, 2013 at 10:43 AM, Peter Zijlstra wrote:
> On Fri, Jun 21, 2013 at 04:20:40PM +0200, Stephane Eranian wrote:
>> This patch series extends perf_events with the ability to sample
>> physical data addresses. This is useful with the memory access
>> sampling mode added just recently. In
On Mon, Jun 24, 2013 at 10:16:23AM +0200, Stephane Eranian wrote:
> Hi,
>
> It applies and compiles for me on tip.git:
>
> 4ce9207 Merge branch 'x86/platform'
ok, now it works.. ;) sry for noise
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a me
On Fri, Jun 21, 2013 at 04:20:40PM +0200, Stephane Eranian wrote:
> This patch series extends perf_events with the ability to sample
> physical data addresses. This is useful with the memory access
> sampling mode added just recently. In particular, it helps
> disambiguate data addresses between tw
Hi,
It applies and compiles for me on tip.git:
4ce9207 Merge branch 'x86/platform'
On Sun, Jun 23, 2013 at 11:58 PM, Jiri Olsa wrote:
> On Fri, Jun 21, 2013 at 04:20:40PM +0200, Stephane Eranian wrote:
>> This patch series extends perf_events with the ability to sample
>> physical data address
On Fri, Jun 21, 2013 at 04:20:40PM +0200, Stephane Eranian wrote:
> This patch series extends perf_events with the ability to sample
> physical data addresses. This is useful with the memory access
> sampling mode added just recently. In particular, it helps
> disambiguate data addresses between tw
This patch series extends perf_events with the ability to sample
physical data addresses. This is useful with the memory access
sampling mode added just recently. In particular, it helps
disambiguate data addresses between two processes, such as
in the case of a shared memory segment mapped at diff
27 matches
Mail list logo
