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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list