linux-kernel - Re: [PATCH v7 3/3] KVM: perf: kvm events analysis tool

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Sep 2012 10:56:11 +0800
From:	Xiao Guangrong <xiaoguangrong@...ux.vnet.ibm.com>
To:	David Ahern <dsahern@...il.com>
CC:	Dong Hao <haodong@...ux.vnet.ibm.com>, acme@...radead.org,
	avi@...hat.com, mtosatti@...hat.com,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	kvm@...r.kernel.org
Subject: Re: [PATCH v7 3/3] KVM: perf: kvm events analysis tool

On 09/13/2012 12:56 PM, David Ahern wrote:

> 
> That suggests what is really needed is a 'live' mode - a continual updating of the output like perf top, not a record and analyze later mode. Which does come back to why I responded to this email -- the syntax is klunky and awkward.
> 
> So, I spent a fair amount of time today implementing a live mode. And after a lot of swearing at the tracepoint processing code I finally have it working. And the format extends easily (meaning < day and the next step) to a perf-based kvm_stat replacement. Example syntax is:
> 
>    perf kvm stat [-p <pid>|-a|...]
> 
> which defaults to an update delay of 1 second, and vmexit analysis.

Hi David,

I am very glad to see the live mode, it is very similar with kvm_stat(*). I think
kvm guys will like it.

> 
> The guts of the processing logic come from the existing kvm-events code. The changes focus on combining the record and report paths into one. The display needs some help (Arnaldo?), but it seems to work well.
> 
> I'd like to get opinions on what next? IMO, the record/report path should not get a foot hold from a backward compatibility perspective and having to maintain those options. I am willing to take the existing patches into git to maintain authorship and from there apply patches to make the live mode work - which includes a bit of refactoring of perf code (like the stats changes).

We'd better keep the record/report function, sometimes, we can only get perf.data
from the customers whose machine can not be reached for us.

Especially, other tracepoints are also interesting for us when the customers encounter
the performance issue, we always ask costumes to use "perf kvm stat -e xxx" to append
other events, like lock:*. Then, we can get not only the information of kvm events
by using 'perf kvm stat' but also other informations like 'perf lock' or 'perf script'
to get the whole sequences.

> 
> Before I march down this path, any objections, opinions, etc?

And, i think "live mode" is also useful for 'perf lock/sched', could you implement it
in perf core?

By the way, the new version of our patchset is ready, do you want to add your implement
after it is accepted by Arnaldo? Or are you going to post it with our patchset together?

Thanks!

* kvm_stat can be found at scripts/kvm/kvm_stat in the code of Qemu which locate at
  https://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/