From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: Marcelo Tosatti <mtosatti@redhat.com>, kvm@vger.kernel.org
Subject: Re: [PATCH 08/20] qemu-kvm: Replace kvm_update_interrupt_request with qemu_cpu_kick
Date: Sun, 29 May 2011 19:55:26 +0200 [thread overview]
Message-ID: <4DE2888E.7040101@web.de> (raw)
In-Reply-To: <4DE277E0.3000106@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1006 bytes --]
On 2011-05-29 18:44, Avi Kivity wrote:
> On 05/29/2011 07:41 PM, Jan Kiszka wrote:
>> >
>> > void qemu_cpu_kick(void *_env)
>> > {
>> > CPUState *env = _env;
>> >
>> > qemu_cond_broadcast(env->halt_cond);
>> > if (!env->thread_kicked) {
>> > qemu_cpu_kick_thread(env);
>> > env->thread_kicked = true;
>> > }
>> > }
>> >
>> > Seems to have redundancies - we're both signalling a condition
>> variable
>> > and sending a signal.
>> >
>>
>> The target may block on the halt condition or run in guest mode. I don't
>> think we can (and should) try to find out which wakeup call is
>> sufficient.
>
> What we could do is make both waiters wait for the same event.
That may only work if we are able to switch halt_cond to a signal-based
mechanism. As usual, a portability issue. I don't think there is much to
win /wrt performance (cond_broadcast is fast). So the question is if
code complexity could actually benefit from this.
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
next prev parent reply other threads:[~2011-05-29 17:55 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-27 12:19 [PATCH 00/20] qemu-kvm: Cleanup and switch to upstream - The Season Final Jan Kiszka
2011-05-27 12:19 ` [PATCH 01/20] qemu-kvm: Move thread-related code to cpus.c Jan Kiszka
2011-05-27 12:19 ` [PATCH 02/20] qemu-kvm: Enable CONFIG_IOTHREAD Jan Kiszka
2011-05-27 12:19 ` [PATCH 03/20] qemu-kvm: Switch to iothread version of qemu_notify_event Jan Kiszka
2011-05-27 12:19 ` [PATCH 04/20] qemu-kvm: Use upstream mutex and conds Jan Kiszka
2011-05-27 12:19 ` [PATCH 05/20] qemu-kvm: Restrict validity of cpu_single_env Jan Kiszka
2011-05-27 12:19 ` [PATCH 06/20] qemu-kvm: Use upstream qemu_mutex_lock/unlock_iothread Jan Kiszka
2011-05-27 12:19 ` [PATCH 07/20] qemu-kvm: Clean up kvm_update_interrupt_request Jan Kiszka
2011-05-29 16:16 ` Avi Kivity
2011-05-29 16:37 ` Jan Kiszka
2011-05-29 16:41 ` Avi Kivity
2011-05-27 12:19 ` [PATCH 08/20] qemu-kvm: Replace kvm_update_interrupt_request with qemu_cpu_kick Jan Kiszka
2011-05-29 16:19 ` Avi Kivity
2011-05-29 16:41 ` Jan Kiszka
2011-05-29 16:44 ` Avi Kivity
2011-05-29 17:55 ` Jan Kiszka [this message]
2011-05-30 15:10 ` Avi Kivity
2011-05-27 12:19 ` [PATCH 09/20] qemu-kvm: Use upstream run_on_cpu and flush_queued_work Jan Kiszka
2011-05-27 12:19 ` [PATCH 10/20] qemu-kvm: Drop kvm_cond_wait Jan Kiszka
2011-05-27 12:19 ` [PATCH 11/20] qemu-kvm: Replace kvm_cpu_is_stopped with cpu_is_stopped Jan Kiszka
2011-05-27 12:19 ` [PATCH 12/20] qemu-kvm: Remove obsolete current_env Jan Kiszka
2011-05-27 12:19 ` [PATCH 13/20] qemu-kvm: Use upstream vcpu pause/resume Jan Kiszka
2011-05-27 12:19 ` [PATCH 14/20] qemu-kvm: Move main loop setup code Jan Kiszka
2011-05-27 12:19 ` [PATCH 15/20] qemu-kvm: Use upstream's way of signaling debug stops Jan Kiszka
2011-05-27 12:19 ` [PATCH 16/20] qemu-kvm: Use upstream main loop Jan Kiszka
2011-05-27 12:19 ` [PATCH 17/20] qemu-kvm: Use upstream main loop initialization Jan Kiszka
2011-05-27 12:19 ` [PATCH 18/20] qemu-kvm: Replace kvm_get_thread_id with qemu_get_thread_id Jan Kiszka
2011-05-27 12:19 ` [PATCH 19/20] qemu-kvm: Use upstream kvm vcpu initialization Jan Kiszka
2011-05-27 12:19 ` [PATCH 20/20] qemu-kvm: Use upstream vcpu loop Jan Kiszka
2011-05-29 16:24 ` [PATCH 00/20] qemu-kvm: Cleanup and switch to upstream - The Season Final Avi Kivity
2011-05-31 13:36 ` Marcelo Tosatti
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=4DE2888E.7040101@web.de \
--to=jan.kiszka@web.de \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.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