On Tue, 3 Mar 2020 at 18:54, Leo Yan <leo.yan@linaro.org> wrote:
>
> Hi Andrea,
>
> On Tue, Mar 03, 2020 at 11:23:29AM -0700, Mathieu Poirier wrote:
> > Hi Andrea,
> >
> > On Tue, 3 Mar 2020 at 09:34, Andrea Brunato <Andrea.Brunato@arm.com> wrote:
> > >
> > > Good afternoon,
> > >
> > > When using perf to record a simple benchmark I see the following warning:
> > >
> > > $ perf record --per-thread -e cs_etm/sinkid=0xa6509eae/u ~/afdo/coremark/coremark/coremark.exe 0x3415 0x3415 0x66 0 7 1 2000 > run2.log
> >
> > What is "sinkid=0xa6509eae" ?
>
> Sink might be ETF/ETR/ETB, I think this is why Mathieu asked the meaning
> for 'sinkid', which we don't which sink you are using.
>
> > > [ perf record: Woken up 6 times to write data ]
> > > Warning:
> > > AUX data lost 6 times out of 6!
> > >
> > > [ perf record: Captured and wrote 0.378 MB perf.data ]
> > >
> > > This is on DB845c (
https://www.96boards.org/product/rb3-platform/), kernel 5.5.0-rc7.
> > >
> > > It looks like perf is losing data and the reported perf.data file is very tiny, given that the application runs for several seconds.
> > > Does anybody have any idea about what it may be causing this?
>
> Just give some info based on my understanding.
>
> For the log "AUX data lost 6 times out of 6!", since you are using
> per-thread mode, so every time when the task switching out, the trace
> data in the sink will be read out and save into aux buffer. But
> usually the sink's buffer is not big (maximum to MBs), so it's easily
> to overwrite the hardware's cycle buffer and the previous trace data
> will be lost. For this reason, it reports "AUX data lost".
>
> > > I've tried adding --mmap-pages=32K,64K to the command for increasing the buffer size, but it's not actually solving the problem
>
> If it's the overflow in the hardware buffer in SRAM, "--mmap-pages"
> option doesn't work, since it only enlarges aux buffer page size but
> cannot change the SRAM size in CoreSight.
>
> To allow the "--mmap-pages" to work with big buffer, the sink needs
> to directly output trace data to DDR, you also need to take care
> what's the buffer mode you are using (flat, sg, CATU).
Everything Leo said above is accurate.
>
> Thanks,
> Leo