Hi Ben, On 2021/4/29 0:22, Ben Gardon wrote: > On Wed, Apr 28, 2021 at 4:34 AM zhukeqian <zhukeqian1@xxxxxxxxxx> 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
