From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Checking guest memory pages changes from host userspace Date: Mon, 22 Jun 2009 11:50:09 +0300 Message-ID: <4A3F45C1.4000201@redhat.com> References: <18C018878FB0244EB71B7FE328978A32679FD52B@rrsmsx503.amr.corp.intel.com> <4A3E5706.9070408@redhat.com> <3574F699-DC93-41EB-9ABC-F246CCE28203@suse.de> <4A3E9186.8020303@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Passera, Pablo R" , "kvm@vger.kernel.org" To: Alexander Graf Return-path: Received: from mx2.redhat.com ([66.187.237.31]:59360 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752168AbZFVItW (ORCPT ); Mon, 22 Jun 2009 04:49:22 -0400 In-Reply-To: <4A3E9186.8020303@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/21/2009 11:01 PM, Avi Kivity wrote: >> I don't know which operation is more frequent - writing into dirty >> mapped memory or reading the dirty map. And I have no idea how long >> it would take to find out dirty pages... > > The cost of write protection is one fault per dirtied spte. The cost > of looking at the dirty bit is a cache miss per spte (could be reduced > by scanning in spte order rather than gfn order). > > The problem is when you have a low percentage of memory dirtied. Then > you're scanning a lot of sptes to find a few dirty ones - so the cost > per dirty page goes up. > > We've talked about write-protecting the upper levels first, but given > a random distribution of writes, that doesn't help much. > Thinking about it a bit more, when we write-protect pages we're O(spte) anyway, so that shouldn't be a barrier. -- error compiling committee.c: too many arguments to function