From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50656) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RX9BH-00062m-Ar for qemu-devel@nongnu.org; Sun, 04 Dec 2011 05:20:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RX9BG-0000l9-8d for qemu-devel@nongnu.org; Sun, 04 Dec 2011 05:20:23 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50177) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RX9BF-0000kv-So for qemu-devel@nongnu.org; Sun, 04 Dec 2011 05:20:22 -0500 Message-ID: <4EDB495C.7050204@redhat.com> Date: Sun, 04 Dec 2011 12:20:12 +0200 From: Avi Kivity MIME-Version: 1.0 References: <20111114182041.43570cdf.yoshikawa.takuya@oss.ntt.co.jp> <4EC0EC90.1090202@redhat.com> <4EC0F3D3.9090907@oss.ntt.co.jp> <4EC10BFE.7050704@redhat.com> <4EC33C0B.1060807@oss.ntt.co.jp> <4EC37D18.4010609@redhat.com> <4ED4AF43.2040003@linux.vnet.ibm.com> <4ED4B574.8090907@oss.ntt.co.jp> <4ED4BFEB.5010600@redhat.com> <4ED4C85A.5020509@linux.vnet.ibm.com> <4ED4C9A3.50504@redhat.com> <4ED4E626.5010507@redhat.com> <4ED5B8F2.2090804@oss.ntt.co.jp> <4ED5BC03.5000901@oss.ntt.co.jp> <4ED79AAE.8000201@redhat.com> <20111203133747.7994cd7a0a69aebe7a33e9f2@gmail.com> In-Reply-To: <20111203133747.7994cd7a0a69aebe7a33e9f2@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 0/4] KVM: Dirty logging optimization using rmap List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Takuya Yoshikawa Cc: KVM , quintela@redhat.com, Marcelo Tosatti , qemu-devel@nongnu.org, Xiao Guangrong , Takuya Yoshikawa On 12/03/2011 06:37 AM, Takuya Yoshikawa wrote: > Avi Kivity 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