> On 10/10/2009 06:55, "Jeremy Fitzhardinge" <jeremy@xxxxxxxx> wrote:
>
> > The kernel does about between 400k and 1.4M/sec, median
> around ~600k,
> > for a git pull (which I think is single-threaded), and about
> > 200k-500k/sec for a kernel compile (-j4 on 2 vcpus).
> Usermode is a much
> > lower rate; around 1000/sec for the kernel compile.
> >
> > Baseline idle is around 1000/sec kernel, 10/sec user.
> >
> > Also, my inline naked rdtsc benchmark shows that the
> emulated rdtsc is
> > taking around 465ns (vs 30, a 15x slowdown).
>
> Hmmm... So at 600k/sec, the kernel spends an appreciable
> amount of time
> (1-2%) doing RDTSCs? And with emulation that'll be more like 25-30%.
>
> It's quite a surprisingly high rate.
>
> -- Keir
I'm trying a kernel compile (-j4, 2 vcpus, 2 pcpus)
and seeing about 1300/sec kernel and 500/sec user.
My "idle" rate appears to be about 400/sec (kernel,
and every now and then a handful of user rdtscs).
That's with a cpu-only load....
# while true; do i=i+1; done && while true; do i=i+1; done
It seems to be about 100/sec for a truly idle domain.
With an NFS untar I am seeing higher numbers though
(~10K/sec).
(All these loads are on a EL5u2 32-bit PV guest.)
Jeremy, were you maybe measuring per hundred seconds, or
per minute? Or, on the git pull, maybe your VNIC
throughput is much much higher than mine and there
is a getnstimeofday() call for each packet?
Another scary thought... what is gcc doing using
rdtsc? Might it be randomly sensitive to the rdtsc
discontinuites one will encounter with migration
and we've just not seen it yet? In other words,
is gcc a "fundamentally broken" app? ;-) And what
is that other usermode app (service?) that seems to use
a handful of rdtsc's when the system is cpu-only loaded?
Is it using rdtsc safely?
The time ratio of emulated rdtsc to native rdtsc matches
what I measured on my machine (360 vs 22), so 15x
seems like a safe multiplier estimate to use.
Curiouser and curiouser...
Dan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home