On Mon, Jul 22, 2013 at 06:18:03PM +0800, liu ping fan 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. > > > 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.
Using eventfds for timeouts is more heavy-weight. It means a file descriptor per timeout and more system calls. We already need to do the poll(2) system call, we might as well make use of the timeout argument. Stefan
