"Daniel P. Berrange" <berrange@xxxxxxxxxx> wrote: > On Wed, Feb 04, 2009 at 02:46:58PM +0000, Daniel P. Berrange wrote: >> A couple of bugs conspired to make libvirtd use 100% CPU usage when the >> --timeout option is used. This is the default for qemu:///session instance >> which are auto-spawned, so quite annoying! >> >> eg libvirt --timeout=30 >> >> >> - The qemudRunLoop() method was registering a timeout on every >> iteration of the loop, when it considered itself inactive, >> even if already registered >> - virEventInteruptLocked() was looking at eventLoop.leader >> and comparing to pthread_self() before anyone used the >> event loop. 'leader' was 0 at this point so it thought it >> had to wake someone up even though no one was waiting in >> the event loop. >> >> The latter bug conspired with the former, so the act of registering >> the timeout, caused it to immediately see a wakeup signal on the >> following poll. So it did another loop iteration, adding another >> timer, getting woken up again, etc 100% cpu follows. >> >> Another minor problem was that when completing an event loop >> iteration, we reset eventloop.leader to '0'. It is not safe to >> assume that pthread_t is an integer like this. The solution is >> to track when something is using the event loop explicitly, and >> not rely on the 'leader' variable, unless we know a thread is >> active. >> >> Finally we never de-registered the shutdown timeout if a new >> client turned up while we were counting down. >> >> This patch addresses all these flaws > > Opps, forgot to remove one chunk of redundant code that'd totally > unregister the timer, when we only want to deactivate it now. Ahh... that looks better. In trying that out, I had just noticed that without that change, --timeout=N didn't work at all when any client turned up during the count-down. ACK -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list