aboutsummaryrefslogtreecommitdiffstats
path: root/tools/blktap
diff options
context:
space:
mode:
authorKeir Fraser <keir.fraser@citrix.com>2009-03-09 09:37:52 +0000
committerKeir Fraser <keir.fraser@citrix.com>2009-03-09 09:37:52 +0000
commit2441e7179c0ffe09dcc9e3fa2276917594760bbd (patch)
tree9d397cf2cce7faf522d15f189e2aea6b532bf0c8 /tools/blktap
parent881f28d8e897daee3d6ba1c591098b50931b6cec (diff)
downloadxen-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