From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33292) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfgZo-0006Ro-G7 for qemu-devel@nongnu.org; Tue, 27 Dec 2011 18:37:01 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RfgZn-0000ba-GA for qemu-devel@nongnu.org; Tue, 27 Dec 2011 18:37:00 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:35737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RfgZn-0000bJ-8X for qemu-devel@nongnu.org; Tue, 27 Dec 2011 18:36:59 -0500 Received: by qcsd15 with SMTP id d15so7722419qcs.4 for ; Tue, 27 Dec 2011 15:36:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 27 Dec 2011 23:36:57 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] interrupt handling in qemu List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Xin Tong Cc: qemu-devel On 27 December 2011 23:12, Xin Tong wrote: > The reason I ask is that I am searching for alternatives to QEMU > current way of handling interrupt (unlink translation blocks on > interrupt). However, an obvious approach - checking for interrupt in > every basic block, =C2=A0seems to be too heavy ( too many tb enters/exits > ). It's not awful -- an extra load-test-branch-not-taken per TB, which IIRC from last time I tried to measure it was ~3% speed penalty, obv. very variable with what the guest code is. I have a half-finished patch for this but since I don't have a decent benchmarking setup I've never got round to submitting it. > Maybe checking interrupt in a few basic blocks might be better, but > what is a good measure for the number of basic blocks to execute > before checking for interrupt ? The trouble is that you can't tell when you're translating the TB whether it's just one in a sequence A->B->C (where you could perhaps skip the check at the start of B), or if you're actually looking at a tight loop B->B (or B->C->B). So you don't have the information conveniently to hand to tell you whether you can skip compiling the interrupt check into this TB. (One heuristic for how often we need to check would be "every N instructions, or at every backwards branch or indirect-branch", but this doesn't fit with the idea of putting the checks at the start of the TB, they'd have to go in the middle of the TB which is probably awkward.) -- PMM