On Tue, Dec 27, 2011 at 6:10 PM, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 28 December 2011 00:43, Xin Tong <xerox.time.t...@gmail.com> wrote: >> Which version of QEMU did you do your test on, and what are the tests. > > It was whatever trunk qemu was a year or so ago, and the test was > just "time to login prompt for ARM guest in system mode". > >> 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 don't suppose you could provide a brief set of instructions for > setting up a benchmark setup like this? (Is this user-mode or > system-mode?)
It is in system mode, the SPECINT2000 benchmarks are running on top of a ubuntu linux. It is not trial to set up. > >> 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. > > Odd. > >> By keeping a counter that decrements on every TB, and when the counter >> reaches 0, the current executing TB checks for interrupt status. > > Decrementing a counter on every TB is going to be slower than > just checking a flag, so you might as well just check the flag. > (If the flag is set you need to handle the interrupt anyway > so there's no point delaying it.) > The point I am trying to make here is that if qemu TB exits for every interrupt, it is going to be too many. What if QEMU exits and handle a few interrupts in one exit. > -- PMM
