From: Anthony Liguori <aliguori@us.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: Amit Shah <amit.shah@redhat.com>,
Peter Crosthwaite <peter.crosthwaite@xilinx.com>,
qemu-devel@nongnu.org, gson@gson.org
Subject: Re: [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread
Date: Thu, 04 Apr 2013 14:54:41 -0500 [thread overview]
Message-ID: <87ppyaysu6.fsf@codemonkey.ws> (raw)
In-Reply-To: <515DCD1E.6050506@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> writes:
> Il 04/04/2013 18:59, Anthony Liguori ha scritto:
>>> >
>>> > The right thing to use would be g_source_add_child_source() and
>>> > g_source_remove_child_source(), but that is only present since glib 2.28
>>> > and we currently require 2.12 (2.20 on Windows).
>> I don't think a child source fixes the problem. The backend definitely
>> has work to do. What we don't know is whether the front end is capable
>> of processing the work.
>>
>> The problem here is that we use polling on the front-end. IOW:
>>
>> 1) Char backend has data and is ready to write.
>> 2) Asks front end if it can write
>> 3) Front end says no
>> 4) Goto (1)
>
> What we used to do is this, however:
>
> 1) Char backend asks front end if it can write
> 2) Front end says no
You're missing a step here. Previously we would drop the data silently.
> 3) poll() goes on without char backend's descriptor
Which is what enabled this.
> 4) Goto (1), then:
> 5) Front end is now available, calls qemu_notify_event()
This still exists FWIW.
> 6) Char backend asks front end if it can write
> 7) Front end says yes
>
> No busy waiting here. Though we don't really do (5) everywhere, because
> for example this patch slipped through the cracks:
Ack.
> http://lists.gnu.org/archive/html/qemu-devel/2012-03/msg03208.html (but
> for the monitor and every consumer running in iothread context it's ok).
>
> You could achieve the same thing by making the io watch a child source
> of the QEMU wrapper. All the wrapper does is add/remove the io watch
> source from its children, depending on can_read.
I don't understand how this solves the problem. There aren't two
sources. There is only a single source (the GIOChannel source).
We override the function pointers to basically do monkey patching of the
GSource.
If I understand your suggestion, it's to add the source as a child of
itself.
>
> Perhaps it's possible without child sources though, by setting the
> callbacks on the glib source directly.
That's what we're doing...
src = g_io_create_watch(channel, G_IO_IN | G_IO_ERR | G_IO_HUP);
g_source_set_funcs(src, &io_watch_poll_funcs);
g_source_set_callback(src, (GSourceFunc)fd_read, user_data, NULL);
There is only one GSource active here.
Regards,
Anthony Liguori
> Paolo
next prev parent reply other threads:[~2013-04-04 19:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 9:04 [Qemu-devel] [RFC PATCH] main-loop: Unconditionally unlock iothread Peter Crosthwaite
2013-04-02 11:11 ` Paolo Bonzini
2013-04-03 2:17 ` Peter Crosthwaite
2013-04-03 6:35 ` Paolo Bonzini
2013-04-03 23:58 ` Peter Crosthwaite
2013-04-04 5:44 ` Paolo Bonzini
2013-04-04 13:49 ` Anthony Liguori
2013-04-04 16:59 ` Anthony Liguori
2013-04-04 17:03 ` Peter Maydell
2013-04-04 18:17 ` Anthony Liguori
2013-04-04 18:57 ` Paolo Bonzini
2013-04-04 19:54 ` Anthony Liguori [this message]
-- strict thread matches above, loose matches on Subject: below --
2013-04-02 8:53 Peter Crosthwaite
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=87ppyaysu6.fsf@codemonkey.ws \
--to=aliguori@us.ibm.com \
--cc=amit.shah@redhat.com \
--cc=gson@gson.org \
--cc=pbonzini@redhat.com \
--cc=peter.crosthwaite@xilinx.com \
--cc=qemu-devel@nongnu.org \
/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).