On 03/21/2012 02:41 AM, Michal Privoznik wrote:
On 21.03.2012 00:14, Eric Blake wrote:
> On machines with massive amounts of CPUs, the gnulib 'test-lock'
> could take minutes, or even appear to deadlock, because of timing
> interactions between multiple cores.
>
> See
https://bugzilla.redhat.com/show_bug.cgi?id=797284.
> For precedence, note that iwhd has done the same:
>
https://lists.gnu.org/archive/html/bug-gnulib/2012-01/msg00311.html
>
> We can re-enable things if gnulib ever analyzes and improves the
> situation.
>
ACK, if user's system can't lock properly he would experience problems
regardless running libvirt.
Thanks; pushed.
The particular gnulib test was just exposing the fact that some locking
patterns don't scale well across large-cpu systems, but I don't know if
that is representative of a glibc bug, a kernel issue, or just something
inherent in the way the test was trying to provide consistent locking
across that many asymmetric NUMA nodes at once. If nothing else, it
goes to show why you should code with as few heavyweight locks as
possible; maybe this is an argument for revisiting the idea of adding a
virObject base class that does lock-less atomic-operation reference
counting, first proposed sometime last year.
--
Eric Blake eblake(a)redhat.com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org