RE: [xen-devel] System time monotonicity

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

> From: Dave Winchell [mailto:dwinchell@xxxxxxxxxxxxxxx]
> Dan asked that I measure the cost of accessing the hpet. My 
> first set of
> measurements indicated that
> for 99.8% of the samples taken the cost is less than 1/2 usec, or 500
> cycles on my machine.
> This is about the cost of a single vmexit, for reference. The cost
> includes the cost
> of taking a spinlock. This cost also includes the overhead of 
> one or two
> rdtsc instructions for the measurement.
> I'm still working with Dan on these measurements as he sees (much)
> higher costs measured from Linux.

FYI, I did a more precise measurement of reading hpet (and pit)
on my machine by modifying the kernel and recording rdtscll
differences around the platform timer reads (as well as the
entire function calls which compares better against my prior
measurements using systemtap).  For HPET reads, about 86% of
the (100000) samples were between 4K and 8K cycles and about
13% were between 16K and 32K cycles.  For PIT reads, all reads
are between 64K and 128K cycles.  (I also measured the rdtscll
calls by putting two calls back-to-back... 90% of them were
between 128-255 cycles and 10% between 64-127 cycles.)

Since my system is 3.0 Ghz, HPET read averages on the order of
3 usec, which is what my previous measure showed.

I suspect that Dave's measurements and mine are "both right"
and that read overhead of HPET varies on different systems.

> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> It used to be deliberately not exposed because Windows had problems
> using it in some cases, iirc. If it's no longer getting hidden in
> newer systems then that's a good thing.

On my box (and several others at Oracle), HPET is present but
disabled by default in the BIOS.

Dan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel