From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51346) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V19bf-00060L-Tx for qemu-devel@nongnu.org; Mon, 22 Jul 2013 02:28:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V19be-0002Fa-IB for qemu-devel@nongnu.org; Mon, 22 Jul 2013 02:28:27 -0400 Received: from goliath.siemens.de ([192.35.17.28]:27272) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V19be-0002F8-8u for qemu-devel@nongnu.org; Mon, 22 Jul 2013 02:28:26 -0400 Message-ID: <51ECD0FF.3020808@siemens.com> Date: Mon, 22 Jul 2013 08:28:15 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <1374396185-10870-1-git-send-email-pingfank@linux.vnet.ibm.com> <429B80A9A0DBF7FBF05E7C5A@nimrod.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: liu ping fan Cc: Kevin Wolf , Stefan Hajnoczi , Alex Bligh , qemu-devel@nongnu.org, Anthony Liguori , Paolo Bonzini On 2013-07-22 06:38, liu ping fan wrote: > 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, Timers, as used in QEMU, are not only for "unimportant" and unlikely-to-fire timeouts. They are also for potential high-rate, high resolution events. Your last series neglects this. We may need two versions of timers - or one interface that caters both use cases properly. Jan > 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 -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux