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. > 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
