qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] [RFC] aio/async: Add timed bottom-halves


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH] [RFC] aio/async: Add timed bottom-halves
Date: Fri, 19 Jul 2013 08:22:53 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7

Il 19/07/2013 03:58, Stefan Hajnoczi ha scritto:
>>   Options:
>>
>>   a) restore alarm timers (at least for the time being). Make all
>>      alarm timers do qemu_notify_event. However, only run the AioContext
>>      clock's timers within aio_poll. This is the least intrusive change.
>>
>>   b) calculate the timeout in aio_poll with respect to the minimum
>>      deadline across all clocks, not just AioContext's clock. Use the
>>      same logic in mainloop.
>>
>>   I'd go for (b), except for the millisecond accuracy thing. So my
>>   temptation (sadly) is (a).
> 
> I think this is a non-issue because host_alarm_handler() can only be
> called from the main loop:
> 
> main-loop.c:qemu_signal_init() sets up signalfd to monitor SIGALRM.
> Therefore we do not asynchronously invoke the SIGALRM signals handler.
> It is only invoked from main-loop.c:sigfd_handler() when the main loop
> runs.
> 
> That's how I read the code.  I haven't checked a running process to be
> sure.

I think you're right.  It was not strictly needed even with alarm
timers, because host_alarm_handler() is called always before
qemu_run_all_timers.  But it made the code more robust.

With your change to delete alarm timers and move the deadline to poll,
the next poll call will have a timeout of 0 and all will be well.

As to millisecond accuracy, as discussed earlier we can use ppoll on
Linux.  This of course should be introduced before alarm timers are
deleted, to avoid breaking bisection.

Paolo

>> 2. If we do delete alarm timers, I'll need to delete the -clock option.
> 
> I noticed this too because I think we should stub it out for
> compatibility.  Accept existing options but ignore them, update
> documentation to state that they are kept for compatibility.
> 
> Stefan
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]