> > Well, as I've said all along, a driver in a dynamically loadable
> > module is OK. Whether sensible or not, customers don't seem to
> > care about that, they only care if you change the kernel bits
> > that gets loaded.
>
> A loadable driver wouldn't be able to claim fixmap slots or anything
> like that, but, yes, it could present an mmapable device.
Hopefully that would be all that would be necessary.
> >> Once you're making kernel changes then you can update the pvclock
> >> mechanism to use the xen clock algorithm, obviating the need for
> >> usermode ABI changes.
> >>
> > Is that working yet (fast vsyscall under Xen)? >:-)
>
> It's just a matter of someone spending some time on it.
> My frustration
> with the pvtsc scheme is that its incredibly niche and is
> only going to
> serve a very small number of users; a similar amount of
> effort spent on
> a vsyscall solution will have a much larger payoff.
Well we at Oracle hope that "users of Oracle DB and Oracle
JRockit on Oracle VM" is not a small niche. Whereas until
the enterprise distros pick up vsyscall+pvclock into a
widely distributed kernel, a system call won't ever be
used by any app that cares about performance.
Think of it as a critical bug fix. Today's Xen fails to correctly
provide the defined behavior of a user instruction used on physical
machines by certain important apps. Latest xen-unstable fixes
the correctness issue, but at a significant loss of performance.
Vsyscall+pvclock is the right answer for the long term, but
apps that try to use it today will see an even larger loss of
performance on the vast majority of machines for the forseeable
future. (AND it won't even be faster than emulation unless
the administrator can guarantee that all apps running on the
guest are fixed to not use rdtsc, so emulation can be disabled.)
That's why I am so persistently trying to find another
solution.
> >> However, if its really the case that the tsc is guaranteed
> >> synchronized,
> >> then the guest can determine that for itself by looking at
> >> cpuid and/or
> >> /proc/cpuinfo (and presumably doing some sanity checking) and
> >> then just
> >> directly use rdtsc, with no need to change either Xen or
> the kernel.
> >>
> > That's exactly what the app is doing when on bare metal.
>
> Sure. And they still need to deal with discontinuities resulting from
> suspend/resume on bare-metal, so dealing with discontinuities
> caused by
> migration is no different. And on bare metal it would need to compute
> the tsc frequency for itself, so it doesn't really need Xen
> support for
> that either.
Yes, the discontinuities resulting from migration ARE different
from suspend/resume on bare metal. If they weren't, I'd
agree that no Xen support is needed.
> > But in virtual unless it gets some kind of notification on
> > migration (which would be cool, but would also require
> > kernel changes?), it can't determine the appropriate
> > scaling factor and offset, or that they need to change.
>
> Well, they have access to xenbus, so they could get the tsc parameters
> that way, along with notifications about changes. It wouldn't be
> completely synchronous, but you'd need to implement the pvclock
> algorithm to do that.
An interesting thought, but unless we can guarantee that
a xenbus notifier is always delivered and processed "immediately"
(e.g. before any userland "pv-rdtsc instructions" are executed)
it won't work.
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home