| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] RE: rdtsc: correctness vs performance on Xen (and KVM?)
> >> Not within today's Xen or Linux (which both assume a global kernel
> >> address space, in particular non-root page table entries
> >> mapping kernel
> >> space to be the same in all address spaces - you'd need
> >> separate entries
> >> at all levels for this).
> >
> > OK, I forgot: No software-accessible TLB.
> >
> > Can you think of any trick (that doesn't require the cost of a
> > trap/hypercall) to allow an app to determine what pcpu
> > it is running on?
>
> I can't think of any that don't require kernel modifications.
> Which takes us
> back to considering vsyscall, perhaps.
>
> -- Keir
If a solution that doesn't require kernel mods is not
possible, then I suspect apps will continue to use
rdtsc as-is and suffer the emulation overhead.
Requiring all customers to update the OS underlying
these apps is a non-starter.
Also, it has yet to be proven that pvclock can
work in a vsyscall. Doesn't the same per-cpu in
userspace problem exist? Pvclock without vsyscall
has been measured and is too slow, so until a vsyscall
version of pvclock
is implemented and measured (let alone upstream or
available in distros), it's hard to call it an
alternative to consider, even for the future.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home