On Mon, Jan 9, 2017 at 2:03 PM, Paolo Bonzini <pbonz...@redhat.com> 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. -- Vincent
