From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49451) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyyZJ-0003NP-Fh for qemu-devel@nongnu.org; Tue, 16 Jul 2013 02:17:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UyyZH-0001hE-OY for qemu-devel@nongnu.org; Tue, 16 Jul 2013 02:17:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UyyZH-0001gp-HH for qemu-devel@nongnu.org; Tue, 16 Jul 2013 02:16:59 -0400 Message-ID: <51E4E54A.10908@redhat.com> Date: Tue, 16 Jul 2013 08:16:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1373127897-3445-1-git-send-email-alex@alex.org.uk> <51E4063D.6010308@redhat.com> <75638CBA408455BF52192DA7@Ximines.local> <51E4613D.9000106@redhat.com> <44590808AF4A6E7DC093637A@nimrod.local> In-Reply-To: <44590808AF4A6E7DC093637A@nimrod.local> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] [RFC] aio/async: Add timed bottom-halves List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org, Stefan Hajnoczi , rth@twiddle.net Il 16/07/2013 01:04, Alex Bligh ha scritto: > Paolo, > > --On 15 July 2013 22:53:17 +0200 Paolo Bonzini wrote: > >> So far you are right. >> >> But this only happens if qemu_aio_wait() actually returns, so that on >> the next call we poll for timers. If QEMU is stuck in qemu_aio_wait()'s >> infinite-timeout poll(), it will never advance and process the timed >> bottom halves. > > I may have misunderstood the code here. I thought what it was doing was > setting the timeout to poll() to 0 if there was a bh queued, 10ms if > there was a bh->idle timeout queued, or infinite otherwise. > > What I changed it to do was set the timeout to: > * 0 if there was an untimed bh ready (no change) > * 10ms if there was an untimed idle bh ready (no change) > * the number of ms to expiry if there is a timed bh ready (rounded up) > * infinite otherwise (no change) > * and if there is more the one, the minimum of those You did. But aio_wait() ignores the timeout. It is only used by the main loop. > So the infinite timeout poll should not be entered if there is a timed > bh there. This of course assumes a single thread as else there is a TOCTOU > problem if a timed bh gets inserted between calculating the expiry time > and the poll. > >> This goes to the question of having aio_notify() or not. If you have >> it, you will immediately process timed BHs that are "born expired". For >> other bottom halves, there will be no difference if you add it or not. > > You've lost me there. I'm taking it by 'born expired' you mean > when poll() is entered, they're already expired. Timed BH's that are > 'born expired' should (with the patch I sent) be treated exactly the > same as untimed BH's, i.e. the timeout to poll should be being > set to zero. Yes, that's exactly what I meant. Looks like you understood well! :) Paolo