This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] Re: Even faster page copy for Xen?

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Jan Beulich <JBeulich@xxxxxxxxxx>, Dulloor <dulloor@xxxxxxxxx>
Subject: Re: [Xen-devel] Re: Even faster page copy for Xen?
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Tue, 10 Aug 2010 13:41:17 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 10 Aug 2010 05:42:12 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <8e0efd21-1863-489c-a58a-317f69646a3b@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acs4iCQ+Gx+Fi/pLRSKWYxQ7nZNbiwAAS8WL
Thread-topic: [Xen-devel] Re: Even faster page copy for Xen?
User-agent: Microsoft-Entourage/
On 10/08/2010 13:31, "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx> wrote:

>> You can do so if you feel like saving/restoring all necessary XMM
>> state isn't going to eat up all of the performance win...
> Again excuse my x86 ignorance, but on some architectures
> floating point registers can be saved/restored "lazily"
> because there is a privileged bit that disables their use
> (which can be trapped and used as a "floating-point dirty" bit).
> Is there anything equivalent for the XMM state?  If so,
> then lazy save might be a good approach.  If not, then I agree
> that the state save/restore overhead might eat up the performance
> win.  (However, if we were to later use Linux memory compaction
> and NUMA page migration, the performance tradeoff might change
> to positive.)

We do lazy FPU/SSE restore already. But in any case, it is questionable how
much faster you can make a non-temporal and/or non-local bulk memory copy:
it ought to be bottlenecked on FSB bandwidth.

 -- Keir

Xen-devel mailing list