> > Other apps (and/or the OS kernel) may use TSC to
> > approximate the passage of time, and for these apps
> > (and gettimeofday in the Linux kernel), this TSC scaling
> > patch is a must. Unfortunately, both kinds of apps could
> > be running simultaneously on the same guest. And
> > in either case, RDTSC frequency may be quite high.
>
> Certainly Solaris relies on the TSC for time-keeping, and uses it very
> heavily. To the extent that I doubt it's even feasible to migrate to a
> machine where scaling needs to be done, and such a migration should be
> refused, since it would essentially kill the guest.
Hmmm... any numbers? Certainly Solaris isn't reading TSC much
more than a thousand times per second, is it? Are you suggesting
that data centers running Solaris guests must segregate sets of
their machines by clock rate and disallow migrations
between the sets?
> > question is: If it is important to ALWAYS emulate RDTSC,
> > can the Xen code be written to handle RDTSC emulation
> > much faster? If it could be made fast enough, the
>
> I'd be amazed if this were possible.
If it were PA-RISC or Itanium, I'd take on the challenge,
but I just don't know x86 well enough. Are traps really
THAT expensive on x86? (If max(TSC/sec/processor)~=1000 and
cycles/emulation~=5000, total degradation would be
less than 1%. (Sounds high, but if the alternative is
clocks going haywire, seems a small price to pay. And
I expect the frequency and cost estimates (1000 and 5000)
are probably too high.)
Also, might turning RDTSC emulation on be much faster
on newer processors than old?
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home