From: Andi Kleen <ak@linux.intel.com>
To: Feng Tang <feng.tang@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Stephane Eranian <eranian@google.com>
Subject: Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format
Date: Thu, 28 Jun 2012 20:35:46 -0700 [thread overview]
Message-ID: <20120629033546.GV4152@tassilo.jf.intel.com> (raw)
In-Reply-To: <20120629093253.3e99ca0e@feng-i7>
> Yeah, that number scared me too when I first saw it, as the time will make
> the script totally useless. Then after migrating to the RAM based database
> file, the database handling time could be cut down to 1 second.
The problem is just that sqlite does a fdatasync for every insert.
Just need to figure out how to tell it to stop doing that.
Shouldn't be too hard ...
But yes /dev/shm should work well enough for now.
>
> I guess the sqlite itself realize the shortcoming too, it also provide a
> native way to use in-memory database by specifying ":memory":
> con = sqlite3.connect(":memory:")
I think it's better to have a file on disk, then you can easily query
more properties just from the command line.
I can see all kinds of interesting data mining on the events
to be enabled by this. They have all the register values and various
other information.
For example if you look for string operations you could do
a histogram over the ECX values and so do a histogram of
memcpy/memset sizes.
[Would be easier if perf could pass in the assembler opcode,
but could be done without)
Or when sampling spinlocks look at the addresses.
Or lots of other things people could imagine.
-Andi
--
ak@linux.intel.com -- Speaking for myself only
next prev parent reply other threads:[~2012-06-29 3:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-28 16:00 [PATCH] perf, x86: Enabled PEBS event to be exported in a raw format Feng Tang
2012-06-28 16:12 ` Peter Zijlstra
2012-06-28 16:15 ` Stephane Eranian
2012-06-28 16:19 ` Peter Zijlstra
2012-06-28 16:27 ` Stephane Eranian
2012-06-28 16:29 ` Peter Zijlstra
2012-06-28 18:26 ` Andi Kleen
2012-06-28 18:20 ` Andi Kleen
2012-06-28 20:51 ` Peter Zijlstra
2012-06-29 1:32 ` Feng Tang
2012-06-29 3:35 ` Andi Kleen [this message]
2012-06-29 12:49 ` Ingo Molnar
2012-07-03 7:36 ` Michael Ellerman
2012-07-03 9:15 ` Peter Zijlstra
2012-07-04 8:07 ` Michael Ellerman
2012-07-04 9:13 ` Peter Zijlstra
2012-07-05 15:57 ` Stephane Eranian
2012-07-07 7:27 ` Michael Ellerman
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=20120629033546.GV4152@tassilo.jf.intel.com \
--to=ak@linux.intel.com \
--cc=acme@redhat.com \
--cc=eranian@google.com \
--cc=feng.tang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=x86@kernel.org \
/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