On Mon, Jul 22, 2013 at 6:18 PM, liu ping fan <qemul...@gmail.com> wrote: > On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh <a...@alex.org.uk> wrote: >> Liu, >> >> >> --On 22 July 2013 12:38:02 +0800 liu ping fan <qemul...@gmail.com> wrote: >> >>> I read your second series, and try to summary the main different between >>> us. Please correct me, if I misunderstood something. >>> --1st. You try to create a separate QemuClock for AioContext. >>> I think QemuClock is the clock event source and we have three >>> classic with fine definition. They should be qemu-wide for time >>> measurement. On the other handler, timer is a concept for timeout, >>> so it can be AioContext-related. So I have patch2&5. >> >> >> Yes and no. QEMUClock is not a clock source. QEMUClock /has/ a clock >> source, and more than one QEMUClock can share the same clock source. >> > Supposed the case sync the time across iothread/vcpu/dataplane, the > vm_clock is a unique interface for all of them. > >> QEMUClock does have its own list of timers, and so if you only >> want to run a subset of timers in aio_poll (which is I believe the >> requirement so not to change the behaviour of existing timers), >> you need a separate QEMUClock. >> >> The approach I took (StefanH's idea) was to put a QEMUClock into >> each AioContext. Arguably you might want to put a set of 3 QEMUClock's >> into each AioContext, one for each clock source. >> >> QEMUClock itself is very lightweight as far as I can tell. >> > I think the weight is not the point here, rather, the concept. >> >>> --2nd. You want to substitute alarm_timer with timeout of poll. >> >> >> Correct. >> >> >>> I try to trigger each specified thread when its deadline comes. >>> But unfortunately, the signal can not be delivered to the specified >>> thread directly, and I need timerfd for each AioContext. (If we can >>> have the equivalent on other platform) >> >> >> Firstly, I can't see the advantage of keeping the alarm_timer stuff around >> at all if we can delete it. Save, of course, that on systems that don't >> have ppoll or equivalent you lose sub-millisecond timing by deleting them. >> The scenior I can figure out is if adopting timeout of poll, then when changing the deadline, we need to invoke poll, and set the new timeout, right?
Regards, Pingfan > I do not think it very clearly. But the final aim is to associate an > eventfd with deadline, and attach the eventfd to g_poll. For linux, > it can be easily achieved by timerfd, for other posix, what I can > thought till now is to distinguish the source of timer in signal > handler, and revoke a eventfd (stands for deadline) on AioContext. > I am not sure whether this is better than timeout of poll. > >> Secondly, I don't understand this point. Let's assume we keep alarm_timers. >> The timers run from signals at the moment (under POSIX) and could easily >> run in their own thread. They synchronise with the thread waiting on poll >> by using the event notifiers. Why do you need to have multiple threads >> dealing with timers? At most one new thread (and quite possibly zero) >> should be sufficient, as all they need to do is write() to the correct >> notifier FD, which will end the relevant poll. Of course if we delete > > Different AioContext may have different deadline, so I separate the > alarm_timers > > Regards, > Pingfan >> alarm_timers this is all irrelevant. >> >> -- >> Alex Bligh
