Browse Prior Art Database

Method to analyze performance for VM guest Disclosure Number: IPCOM000244421D
Publication Date: 2015-Dec-10

Publishing Venue

The Prior Art Database


This disclosure details methods to do performance measurement for VM guest directly from host. 2 methods are raised up and for use in different circumstances: 1st one consists of three parts, the tools runs in the host, the agent runs in the guest and the communication protocol between them. The agent is called Perf-agent which is new in contrast to the performance tools we now have. The perf-agent itself have many function layers including Unix Sock Layer, Data Compress/Decompress Layer, Request Analysis/Data Encapsulation Layer, Generic API layer and Guest OS Adapter Layer.

2nd method involves a mapping mechanism to analyze performance data collected from hypervisor, representing a system that has potentially a hierarchy of 7 or more layers in to one which has 4 layers.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 19% of the total text.

Page 01 of 10

Method to analyze performance for VM guest

A complete performance toolchain normally consists of a suite of tools to collect, reduce and format performance data, in order to identify hotspots. Generally, the toolchain provides sampling per task, per CPU and per workload, etc.

In virtualized environment, each VM guest machine is a process or address space running in host, so we can sample a guest machine in a host through specifying its process id or address space id. However, assuming there are several workloads running in a guest(and this is the common case), users hope to analyze performance data for one specified workload in the guest. From the users' perspective, for this situation, there are 2 possible approaches:

1) Users can login the guest and start sampling within the guest.

2) Users can start sampling within the host directly.

For the 2nd method, there is no convenient way so far. One workaround is to make one workload take up one guest, so different workloads will run on different guests. It's not a good way as it brings about guest resource waste.

There isn't a solution for the traditional performance tools supporting running on KVM but just fetch data from a whole guest image . Hence a better mechanism is needed to support this feature.

Prior Art

1)Filters the samples of a particular KVM guest. Guest process id can be obtained from host system, for instance, "/sys/kernel/debug/xxx/kvm-"guest process id" on the KVM host.


This method still takes the guest as one process.

2)Perf can sample guest os kernel except guest os user space. For instance, running "perf kvm --host --guest --guestkallsyms=/guest/kallsyms --guestmodules=/guest/modules top", then you can get the top 10 hotspots in guest kernel as below: -------------------------------------------------------------------------------------------------------------------------- PerfTop: 16010 irqs/sec kernel:59.1% us: 1.5% guest kernel:31.9% guest us: 7.5% exact: 0.0% [1000Hz cycles], (all, 16 CPUs) -------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO

_______ _____ _________________________ _______________________

38770.00 20.4% __ticket_spin_lock [guest.kernel.kallsyms]

22560.00 11.9% ftrace_likely_update [kernel.kallsyms]

9208.00 4.8% __lock_acquire [kernel.kallsyms]

5473.00 2.9% trace_hardirqs_off_caller [kernel.kallsyms]

5222.00 2.7% copy_user_generic_string [guest.kernel.kallsyms]


Page 02 of 10

This tool can only provide guest os kernel samples,but no user space samples.

3)US 8607228 B2: Virtualizing performance counters

Description: Embodiments of apparatuses, methods, and systems for virtualizing performance counters are disclosed. In one embodiment, an apparatus includes a counter, a counter enable storage location, counter enable logic, and virtual machine control logic. The counter enable storage location is store a counter enable indicator. The counte...