From: "Daniel P. Berrange" <berrange@redhat.com>
To: Michael Roth <mdroth@linux.vnet.ibm.com>
Cc: qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] qemu guest agent spins in poll/nanosleep(100ms) when nothing is listening on host
Date: Fri, 7 Oct 2011 10:00:19 +0100 [thread overview]
Message-ID: <20111007090017.GA31228@redhat.com> (raw)
In-Reply-To: <0MK0K5-1RB6T20K73-001FaS@mrelay.perfora.net>
On Thu, Oct 06, 2011 at 04:15:07PM -0500, Michael Roth wrote:
> On Thu, 6 Oct 2011 12:31:05 +0100, "Daniel P. Berrange" <berrange@redhat.com> wrote:
> > I get the feeling that this kind of problem inherant in the use of any
> > virtio-serial channel, in the same way you can't detect EOF for a regular
> > serial device channel either. Given that virtio-serial is a nice paravirt
> > device, is there anything we can do to it, to allow better handling of
> > EOF by applications ?
>
> Indeed, and there was a discussion a while back where I think we had tentative
> agreement on a path forward for this. Unfortunately there doesn't seem to be
> a clear solution for doing it purely in guest-userspace:
>
> http://www.mail-archive.com/qemu-devel@nongnu.org/msg57002.html
>
> The gist of it is basically making the (guest-side) virtio-serial chardev
> behave more like a unix socket, i.e. if the host hangs up you get a single EOF
> and then your FD becomes invalid, at which point you need to re-open the
> chardev to get a valid FD. This could potentially be done with via a new set of
> -chardev/-device flags.
Ah interesting idea.
> > Or perhaps there is some way to make use of epoll() in edge-triggered
> > mode to detect it already, because IIUC, edge-triggered mode should only
> > fire once for the EOF condition, and then not fire again until something
> > in the host actually sends some data ?
> >
> > Of course glib's event loop doesn't support edge-triggered events/epoll,
> > but perhaps we could just call epoll() directly in the event handler,
> > instead of the usleep() call ?
>
> That's definitely worth looking into. Has the 100ms sleep been causing any
> issues though? My main concern with the polling behavior was less a matter of
> performance than being able to provide a "session" where the start and end
> of a stream could be reliably determined, which we don't have currently. But
> the guest agent has since been reworked to persist state between host
> connects/disconnects so it didn't seem to be a major issue anymore.
We're intending to have the agent installed in all Fedora 16 guests and
later guests by default, and used by libvirt for shutdown/reboot. so I
was just looking at how it was working to ensure there are no surprises
and happened to notice the wakeups when disconnected on the host. So it
hasn't actually caused any problems for me, I just have a general desire
to ensure any code doesn't do frequent wakeups when there's no work todo.
Regards,
Daniel
--
|: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
prev parent reply other threads:[~2011-10-07 9:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-06 11:31 [Qemu-devel] qemu guest agent spins in poll/nanosleep(100ms) when nothing is listening on host Daniel P. Berrange
2011-10-06 21:15 ` Michael Roth
2011-10-07 9:00 ` Daniel P. Berrange [this message]
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=20111007090017.GA31228@redhat.com \
--to=berrange@redhat.com \
--cc=mdroth@linux.vnet.ibm.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).