[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.
Right.
>
> 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