Messages in this thread | | | Subject | Re: [RFC PATCH v2 2/2] KVM: x86: Not wr-protect huge page with init_all_set dirty log | From | Keqian Zhu <> | Date | Thu, 29 Apr 2021 11:30:52 +0800 |
| |
Hi Ben,
On 2021/4/29 0:22, Ben Gardon wrote: > On Wed, Apr 28, 2021 at 4:34 AM zhukeqian <zhukeqian1@huawei.com> wrote: >> >> Oh, I have to correct myself. >> >> without this opt: >> first round dirtying: write fault and split large mapping >> second round: write fault >> >> with this opt: >> first round dirtying: no write fault >> second round: write fault and split large mapping >> >> the total test time is expected to be reduced. > > Oh yeah, good point. So we should really see the savings in the first > round dirty memory time. Good catch. > [...]
>>> It would probably also serve us well to have some kind of "hot" subset >>> of memory for each vCPU, since some of the benefit of lazy large page >>> splitting depend on that access pattern. >>> >>> 3. Lockstep dirtying and dirty log collection >>> While this test is currently great for timing dirty logging >>> operations, it's not great for trickier analysis, especially >>> reductions to guest degradation. In order to measure that we'd need to >>> change the test to collect the dirty log as quickly as possible, >>> independent of what the guest is doing and then also record how much >>> "progress" the guest is able to make while all that is happening. >> Yes, make sense. >> >> Does the "dirty log collection" contains "dirty log clear"? As I understand, the dirty log >> collection is very fast, just some memory copy. But for "dirty log clear", we should modify mappings >> and perform TLBI, the time is much longer. > > Yeah, sorry. By dirty log collection I meant get + clear since the > test does both before it waits for the guest to dirty all memory > again. I see.
> >> >>> >>> I'd be happy to help review any improvements to the test which you >>> feel like making. >> Thanks, Ben. emm... I feel very sorry that perhaps I don't have enough time to do this, many works are queued... >> On the other hand, I think the "Dirtying memory time" of first round can show us the optimization. > > No worries, I think this is a good patch either way. No need to block > on test improvements, from my perspective. OK, thanks.
BRs, Keqian
| |