Re: [RFC] Paravirt timer for KVM

Glauber de Oliveira Costa
2007-10-15T17:38:35Z

On 10/12/07, Hollis Blanchard <hollisb-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org> wrote:
> > 2) the TSC would have to be used as a clocksource. You don't know the
> > frequency which is the first problem with using the TSC but some systems
> > have a TSC that changes frequencies. A PV time source gives you more
> > stable clocksource (although as in glommer's patch, when the TSC can be
> > used, it's better to use it).
>
> As I understand it, the TSC is based on CPU frequency, which changes
> with power management. Architectural bug.
No. The TSC _used_ to be tied to CPU frequency. Current architectural
trends keep it constant, and provides other methods for cycle
counting. So in newer machines, the tsc should be constant.

> However, PV time still doesn't help here:
> * The TSC is _user_ accessible, so PV time support in the guest
> kernel doesn't solve the problem.
I'm not sure about which (of them) problem you are talking about here.

> * It looks like external agents can perform out-of-kernel
> frequency scaling on x86 (at least I see options for it on IBM
> blades). So there must already exist some mechanism for a kernel
> to be informed that the TSC frequency has been changed.

If the TSC frequency can be changed, I don't use tsc as a ultimate
resort of timing at all, but rather, just for micro-adjustments.

> > 3) a PV clock can support stolen time calculation which there really
> > isn't a concept of with emulation.
>
> This is true, and I know other platforms support this functionality. I
> think it's mostly useful for process time accounting. Is that actually
> supported in this patch?
>
> --
> Hollis Blanchard
> IBM Linux Technology Center
>
>

--
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."