| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home