Files
kernel_arpi/include/uapi/linux
Jay Zhou 3c9bd4006b KVM: x86: enable dirty log gradually in small chunks
It could take kvm->mmu_lock for an extended period of time when
enabling dirty log for the first time. The main cost is to clear
all the D-bits of last level SPTEs. This situation can benefit from
manual dirty log protect as well, which can reduce the mmu_lock
time taken. The sequence is like this:

1. Initialize all the bits of the dirty bitmap to 1 when enabling
   dirty log for the first time
2. Only write protect the huge pages
3. KVM_GET_DIRTY_LOG returns the dirty bitmap info
4. KVM_CLEAR_DIRTY_LOG will clear D-bit for each of the leaf level
   SPTEs gradually in small chunks

Under the Intel(R) Xeon(R) Gold 6152 CPU @ 2.10GHz environment,
I did some tests with a 128G windows VM and counted the time taken
of memory_global_dirty_log_start, here is the numbers:

VM Size        Before    After optimization
128G           460ms     10ms

Signed-off-by: Jay Zhou <jianjay.zhou@huawei.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-03-16 17:57:37 +01:00
..
2019-12-18 18:07:31 +01:00
2019-03-07 18:32:01 -08:00
2020-01-22 16:30:10 -08:00
2019-10-09 22:31:14 -04:00
2019-09-25 17:51:39 -07:00
2019-08-02 14:44:02 +10:00
2019-09-16 10:18:01 -04:00
2019-06-14 15:00:51 +05:30
2020-01-18 09:19:18 -05:00
2019-03-27 13:30:07 -07:00
2019-08-12 19:33:50 -07:00
2019-12-11 15:31:52 +01:00
2020-01-09 18:41:41 -08:00
2019-09-08 15:37:04 +02:00
2020-02-07 14:39:38 +09:00
2019-08-19 13:04:45 -07:00
2019-05-28 21:37:30 -07:00
2020-01-18 09:19:18 -05:00
2019-10-02 20:32:27 -06:00
2019-07-30 20:34:34 +02:00
2019-12-18 10:37:18 +01:00
2020-01-14 12:20:48 +01:00
2020-01-26 15:28:47 +01:00
2019-11-13 12:15:34 -08:00
2019-12-18 18:07:31 +01:00
2020-01-26 15:28:47 +01:00
2020-01-04 13:49:51 +08:00
2019-12-09 09:59:07 +01:00
2019-09-18 20:17:50 +02:00
2019-08-01 21:49:46 +02:00