[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
Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support
Mon, 9 Jan 2017 17:54:13 +0100
On Mon, Jan 9, 2017 at 2:03 PM, Paolo Bonzini <address@hidden> wrote:
> 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?
The same kind of random numbers so far.
By the way I have added the THREAD_SET_CONTEXT flag to the
OpenThread call in qemu_thread_get_handle() function, as I was getting
ACCESS_DENIED on the QueueUserApc call. Probably not terribly harmful.
I will publish the v6 series with this and continue my benchmarking quest.
> Windows delivers the scheduler tick to the first physical CPU. Try
> pinning QEMU away from the first CPU.
Ok interesting, I will give it a try.