From: Paolo Bonzini <pbonzini@redhat.com>
To: Vincent Palatin <vpalatin@chromium.org>
Cc: Yu Ning <yu.ning@linux.intel.com>,
Eduardo Habkost <ehabkost@redhat.com>,
"Michael S . Tsirkin" <mst@redhat.com>,
Stefan Weil <sw@weilnetz.de>,
Marcelo Tosatti <mtosatti@redhat.com>,
qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support
Date: Mon, 9 Jan 2017 14:03:24 +0100 [thread overview]
Message-ID: <459d4c70-aaa7-0d4d-e6c2-5a439243e481@redhat.com> (raw)
In-Reply-To: <CAP_ceTx+SXzZeg1BrF9ibAEm6MvBma+aMseMzLMcrQV_JjeOXg@mail.gmail.com>
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
next prev parent reply other threads:[~2017-01-09 13:03 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-19 16:24 [Qemu-devel] [PATCH v5 0/4] Add HAX support Vincent Palatin
2016-12-19 16:24 ` [Qemu-devel] [PATCH v5 1/4] kvm: move cpu synchronization code Vincent Palatin
2016-12-19 16:24 ` [Qemu-devel] [PATCH v5 2/4] target-i386: Add Intel HAX files Vincent Palatin
2016-12-19 16:24 ` [Qemu-devel] [PATCH v5 3/4] Plumb the HAXM-based hardware acceleration support Vincent Palatin
2016-12-22 9:57 ` Paolo Bonzini
2017-01-05 13:50 ` Vincent Palatin
2017-01-05 14:01 ` Paolo Bonzini
2017-01-05 21:38 ` Paolo Bonzini
2017-01-06 14:08 ` Vincent Palatin
2017-01-09 13:03 ` Paolo Bonzini [this message]
2017-01-09 16:54 ` Vincent Palatin
2017-01-09 6:17 ` Yu Ning
2016-12-19 16:24 ` [Qemu-devel] [PATCH v5 4/4] hax: add Darwin support Vincent Palatin
2016-12-22 9:49 ` Paolo Bonzini
2017-01-05 13:50 ` Vincent Palatin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=459d4c70-aaa7-0d4d-e6c2-5a439243e481@redhat.com \
--to=pbonzini@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=mtosatti@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=sw@weilnetz.de \
--cc=vpalatin@chromium.org \
--cc=yu.ning@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).