public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.

  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