From: Peter Zijlstra <peterz@infradead.org>
To: Han Pingtian <phan@redhat.com>
Cc: linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>,
jolsa@redhat.com
Subject: Re: perf complains losting events
Date: Wed, 03 Aug 2011 12:54:11 +0200 [thread overview]
Message-ID: <1312368852.1147.290.camel@twins> (raw)
In-Reply-To: <20110803102858.GB2790@hpt.nay.redhat.com>
On Wed, 2011-08-03 at 18:28 +0800, Han Pingtian wrote:
> Hi,
>
> I find there is a comment about losting events:
>
> /*
> * The kernel collects the number of events it couldn't send in a stretch and
> * when possible sends this number in a PERF_RECORD_LOST event. The number of
> * such "chunks" of lost events is stored in .nr_events[PERF_EVENT_LOST] while
> * total_lost tells exactly how many events the kernel in fact lost, i.e. it is
> * the sum of all struct lost_event.lost fields reported.
> *
> * The total_period is needed because by default auto-freq is used, so
> * multipling nr_events[PERF_EVENT_SAMPLE] by a frequency isn't possible to get
> * the total number of low level events, it is necessary to to sum all struct
> * sample_event.period and stash the result in total_period.
> */
>
> So my question is, whether the losting of events is a problem?
> I have saw it many times:
>
> [root@hp-dl580g7-01 perf]# ./perf kmem record sleep 1
> [ perf record: Woken up 0 times to write data ]
> [ perf record: Captured and wrote 21.789 MB perf.data (~951977 samples)
> ]
> Processed 0 events and LOST 76148!
>
> Check IO/CPU overload!
>
> [root@hp-dl580g7-01 perf]# ./perf kmem stat
> Processed 0 events and LOST 76148!
>
> Check IO/CPU overload!
>
>
> SUMMARY
> =======
> Total bytes requested: 5725028
> Total bytes allocated: 6291512
> Total bytes wasted on internal fragmentation: 566484
> Internal fragmentation: 9.003941%
> Cross CPU allocations: 28/84295
Just means there's too many event to process, if you run record as a
realtime task its less:
$ perf record -a -r 1 -R -f -c 1 -e kmem:kmalloc -e kmem:kmalloc_node -e
kmem:kfree -e kmem:kmem_cache_alloc -e kmem:kmem_cache_alloc_node -e
kmem:kmem_cache_free -- sleep 2
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 3.642 MB perf.data (~159113 samples) ]
Processed 0 events and LOST 7213!
On the question on if its a problem, that very much depends on what you
want to do and what kind of precision you need from you data..
I suspect that once we start writing one file per cpu this again will
improve somewhat. Acme was going to work on that.. dunno what his plans
are.
next prev parent reply other threads:[~2011-08-03 10:54 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-03 10:28 perf complains losting events Han Pingtian
2011-08-03 10:54 ` Peter Zijlstra [this message]
2011-08-03 14:11 ` David Ahern
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1312368852.1147.290.camel@twins \
--to=peterz@infradead.org \
--cc=acme@redhat.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=phan@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox