diff options
author | Keir Fraser <keir.fraser@citrix.com> | 2009-03-09 09:37:52 +0000 |
---|---|---|
committer | Keir Fraser <keir.fraser@citrix.com> | 2009-03-09 09:37:52 +0000 |
commit | 2441e7179c0ffe09dcc9e3fa2276917594760bbd (patch) | |
tree | 9d397cf2cce7faf522d15f189e2aea6b532bf0c8 /tools/blktap | |
parent | 881f28d8e897daee3d6ba1c591098b50931b6cec (diff) | |
download | xen-2441e7179c0ffe09dcc9e3fa2276917594760bbd.tar.gz xen-2441e7179c0ffe09dcc9e3fa2276917594760bbd.tar.bz2 xen-2441e7179c0ffe09dcc9e3fa2276917594760bbd.zip |
Add vcpu_migration_delay=<microsecs> boot option to scheduler
The idea is borrowed from Linux kernel: if the vCPU is just
scheduled out and put to run-queue, it's likely cache-hot on its
current pCPU, and it may be scheduled in in a short period of time;
however, if vCPU is migrated to another pCPU, it need to re-warm the
cache.
The patch introduces an option vcpu_migration_delay to avoid
aggressive vCPU migration (actually we really see migration frequency
is very high most of the time.), while in the meantime keeping load
balancing over slightly longer time scales.
Linux kernel uses 0.5ms by default. Considering the cost may be
higher (e.g. VMCS impact) than in native, vcpu_migration_delay=1000 is
chosen for our tests, which are performed on a 4x 6-core Dunnington
platform. In 24-VM case, there is ~2% stable performance gain for
enterprise workloads like SPECjbb and sysbench. If HVM is with
stubdom, the gain is more: 4% for the same workloads.
Signed-off-by: Xiaowei Yang <xiaowei.yang@intel.com>
Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
Diffstat (limited to 'tools/blktap')
0 files changed, 0 insertions, 0 deletions