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?

> >> Why would you say using xmm/sse in Xen is a bad idea ? We already
> have a
> >> copy_page_sse2 (in copy_page.S) in our code base and available (by
> default)
> >> for x86_64. Is it a bad idea to use that ?
> >
> > Never mind about copy_page_sse2 ! That function name is misleading.
> Why - it is code that's dependent on SSE2 to be available. Note it
> doesn't have 'xmm' in its name - that indeed would be misleading.
> > But, still ... I need a copy_page routine and was planning to use
> sse.
> > Is that not fine ?
> 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.)

Xen-devel mailing list