Re: [Qemu-devel] interrupt handling in qemu

[Xin Tong]

On Tue, Dec 27, 2011 at 4:36 PM, Peter Maydell <address@hidden> wrote:
> On 27 December 2011 23:12, Xin Tong <address@hidden> 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,  seems 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 ?
>

Which version of QEMU did you do your test on, and what are the tests.
I modified QEMU to check for interrupt status at the end of every TB
and ran it on SPECINT2000 benchmarks with QEMU 0.15.0. The performance
is 70% of the unmodified one for some benchmarks on a x86_64 host. I
agree that the extra load-test-branch-not-taken per TB is minimal, but
what I found is that the average number of TB executed per TB enter is
low (~3.5 TBs), while the unmodified approach has ~10 TBs per TB
enter. this makes me wonder why. Maybe the mechanism i used to gather
this statistics is flawed. but the performance is indeed hindered.

> 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.)

By keeping a counter that decrements on every TB, and when the counter
reaches 0, the current executing TB checks for interrupt status. this
way, we can control the dynamic number of TBs executed per interrupt
check. But it is going to be introducing some more overhead. Probably
3% - 5%

---Xin .

>
> -- PMM