From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V17tC-0007DF-30 for qemu-devel@nongnu.org; Mon, 22 Jul 2013 00:38:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V17tA-0000ea-GG for qemu-devel@nongnu.org; Mon, 22 Jul 2013 00:38:26 -0400 Received: from mail-la0-x235.google.com ([2a00:1450:4010:c03::235]:59220) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V17tA-0000eQ-9m for qemu-devel@nongnu.org; Mon, 22 Jul 2013 00:38:24 -0400 Received: by mail-la0-f53.google.com with SMTP id fj20so3091183lab.40 for ; Sun, 21 Jul 2013 21:38:23 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <429B80A9A0DBF7FBF05E7C5A@nimrod.local> References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com> <429B80A9A0DBF7FBF05E7C5A@nimrod.local> From: liu ping fan Date: Mon, 22 Jul 2013 12:38:02 +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 Sun, Jul 21, 2013 at 5:53 PM, Alex Bligh wrote: > Liu, > > > --On 21 July 2013 16:42:57 +0800 Liu Ping Fan wrote: > >> Currently, the timers run on iothread within BQL, so virtio-block >> dataplane can not use throttle, as Stefan Hajnoczi pointed out in his >> patches to port dataplane onto block layer.(Thanks, Stefan) To enable >> this feature, I plan to enable timers to run on AioContext's thread. And >> maybe in future, hpet can run with its dedicated thread too. >> >> Also, I see Alex Bligh is on the same effort by another method,(it is a >> good idea) "[RFC] aio/async: Add timed bottom-halves". > > > Stefan & Paolo did not like that method much, so I did a third method > (posted yesterday) suggested by Stefan which adds a clock to AioContext (to > which timers can be attached), deletes ALL the alarm_timer stuff (which was > very cathartic), uses timeouts on the g_poll, and adds ppoll where this is > available. Series at: > http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg03334.html > > I suspect this also overlaps with your code. > > So now we have 3 methods to do similar things! > > One advantage of my approach is that it removes more code than it adds > (by quite a margin). However, alarm timers could have been left in. > What's the advantage in giving an AioContext its own alarm timer as > opposed to just its own clock? > 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. --2nd. You want to substitute alarm_timer with timeout of poll. 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) Anything else? Thanks and regards, Pingfan > -- > Alex Bligh