[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware accelerati
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support |
Date: |
Mon, 9 Jan 2017 14:03:24 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 |
On 06/01/2017 15:08, Vincent Palatin wrote:
>>>>> Apart from the above change, can you check if there are some less
>>>>> heavyeight methods to force an exit? I can think of QueueUserAPC with
>>>>> an empty pfnAPC here, and SleepEx(0, TRUE) in qemu_hax_cpu_thread_fn
>>>>> before qemu_wait_io_event_common.
>>>> Actually I don't know a good test case to verify such a change, any advice
>>>> ?
>> In fact there is a race anyway:
> Thanks for the detailed examples and thoughts.
> The timing/benchmarking code might actually need some kind of per-vcpu
> time storage, but that's a detail.
> I have experimented with it and so far, I have mainly generated random
> numbers ...
> I have yet to find a use-case where the current code (with
> SuspendThread/ResumeThread) yields a better latency than just nothing
> instead :(
:) Does QueueUserAPC generate better latency?
Windows delivers the scheduler tick to the first physical CPU. Try
pinning QEMU away from the first CPU.
Paolo