[Top][All Lists]

[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: Vincent Palatin
Subject: Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support
Date: 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]