[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/4] KVM: Dirty logging optimization using rmap

From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH 0/4] KVM: Dirty logging optimization using rmap
Date: Sun, 04 Dec 2011 12:20:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0

On 12/03/2011 06:37 AM, Takuya Yoshikawa wrote:
> Avi Kivity <address@hidden> wrote:
> > That's true.  But some applications do require low latency, and the
> > current code can impose a lot of time with the mmu spinlock held.
> > 
> > The total amount of work actually increases slightly, from O(N) to O(N
> > log N), but since the tree is so wide, the overhead is small.
> > 
> Controlling the latency can be achieved by making the user space limit
> the number of dirty pages to scan without hacking the core mmu code.
>       The fact that we cannot transfer so many pages on the network at
>       once suggests this is reasonable.

That is true.  Write protecting everything at once means that there is a
large window between the sampling the dirty log, and transferring the
page.  Any writes within that window cause a re-transfer, even when they
should not.

> With the rmap write protection method in KVM, the only thing we need is
> a new GET_DIRTY_LOG api which takes the [gfn_start, gfn_end] to scan,
> or max_write_protections optionally.


>       I remember that someone suggested splitting the slot at KVM forum.
>       Same effect with less effort.
> QEMU can also avoid unwanted page faults by using this api wisely.
>       E.g. you can use this for "Interactivity improvements" TODO on
>       KVM wiki, I think.
> Furthermore, QEMU may be able to use multiple threads for the memory
> copy task.
>       Each thread has its own range of memory to copy, and does
>       GET_DIRTY_LOG independently.  This will make things easy to
>       add further optimizations in QEMU.
> In summary, my impression is that the main cause of the current latency
> problem is not the write protection of KVM but the strategy which tries
> to cook the large slot in one hand.
> What do you think?

I agree.  Maybe O(1) write protection has a place, but it is secondary
to fine-grained dirty logging, and if we implement it, it should be
after your idea, and further measurements.

error compiling committee.c: too many arguments to function

reply via email to

[Prev in Thread] Current Thread [Next in Thread]