[root@centos7 opt]# cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core) 

[root@centos7 opt]# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Model name:            Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
Stepping:              7
CPU MHz:               1627.984
BogoMIPS:              6185.67
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K
NUMA node0 CPU(s):     0-3

[root@centos7 opt]# rpm -qa |grep qemu

As above,both of Host and guest are centos7

In Host, "lscpu" will show the L1/L2/L3 cache info. Guest also have such cache info when use "lscpu", because of the guest is implemented as a host standard process, I want to know the L1/L2/L3 cache which see in guest is really matter for guest? cache info in guest


It depends. Certainly the cache topology (which virtual CPUs share a cache) is used by the Linux kernel scheduler in the guest when enqueueing tasks on vCPUS.

If the guest is aware that vCPUS physically share a last-level cache (LLC, usually L3) cache enqueueing tasks is relatively cheap operation that consists of adding the task to a list and setting some bits in a data structure.

On the other hand, if vCPUs do not share an LLC an inter-processor interrupt (IPI) needs to be sent to the destination vCPU which is much more expensive, especially on a guest where handling interrupts requires switching into the host via VMEXIT.

Qemu recently added support for a virtual L3 cache option which allows you to tell the guest about these relationships if it can't figure out on its own. The patch also have a pretty nice description of the performance wins achievable.


I don't think it should matter.

The host makes this data available to the guest, via a virtual CPU/Core. I can imagine that the host can provide the guest with arbitrary values without really affecting performance that much, since it's the host that ultimately determines performance anyway.

On the other hand, if KVM does bare metal virtualisation, maybe the cache levels reported by the guest represents a direct correlation with the real CPU, since the guest has direct access to the hardware CPU. Thus installing a better CPU will give better performance in the guest.

  • I think so, but in guest, cat /proc/cpuinfo | grep flags show different with Host flags, I doubt this flags will impact guest application performance
    – jython.li
    Jun 17 '16 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.