>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 21.01.10 11:26 >>>
>Hm, okay. Another thing to consider is not using ticket locks when running
>on Xen. Regardless of slow wakeup times (and you can't really depend on them
>being fast, in general, in a virtualised environment) experiments have shown
>that, as you might expect, contended ticket locks perform *abysmally* in
>virtualised environments.
But that's exactly why we use the polling method: That way we don't
need to wake up all potential waiters, but just the one that's going to
get the lock next. We now even go further and detect whether the
lock owner is not currently running, and go polling right away (instead
of spinning on the lock a few hundred times first).
>Turning off our major source of power-management wins by default in
>Xen 4.0 is not really a goer.
I can see your point. But how can you consider shipping with something
apparently severely broken. As said before - the fact that this manifests
itself by hanging many-vCPU Dom0 has the very likely implication that
there are (so far unnoticed) problems with smaller Dom0-s. If I had a
machine at hand that supports C3, I'd try to do some measurements
with smaller domains...
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel