[libvirt] PATCH: Prevent libvirtd 100% CPU usage when --timeout is used

Jim Meyering jim at meyering.net
Wed Feb 4 15:22:02 UTC 2009


"Daniel P. Berrange" <berrange at redhat.com> 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




More information about the libvir-list mailing list