From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1DCG-0003nT-15 for qemu-devel@nongnu.org; Mon, 22 Jul 2013 06:18:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V1DCC-0000aE-SL for qemu-devel@nongnu.org; Mon, 22 Jul 2013 06:18:27 -0400 Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:62399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V1DCC-0000a7-LC for qemu-devel@nongnu.org; Mon, 22 Jul 2013 06:18:24 -0400 Received: by mail-la0-f53.google.com with SMTP id fj20so3339010lab.12 for ; Mon, 22 Jul 2013 03:18:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <628DFBF37B094813C72B6DBF@Ximines.local> References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com> <429B80A9A0DBF7FBF05E7C5A@nimrod.local> <628DFBF37B094813C72B6DBF@Ximines.local> From: liu ping fan Date: Mon, 22 Jul 2013 18:18:03 +0800 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Qemu-devel] [RFC 0/8] arm AioContext with its own timer stuff List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Kevin Wolf , Stefan Hajnoczi , Jan Kiszka , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini On Mon, Jul 22, 2013 at 5:40 PM, Alex Bligh wrote: > Liu, > > > --On 22 July 2013 12:38:02 +0800 liu ping fan 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