All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.