All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: arun@linux.vnet.ibm.com, jvrao@linux.vnet.ibm.com,
	qemu-devel@nongnu.org, aneesh.kumar@linux.vnet.ibm.com
Subject: [Qemu-devel] Re: [v1 PATCH 2/3]: Helper routines to use GLib threadpool infrastructure in 9pfs.
Date: Wed, 16 Mar 2011 08:10:41 -0500	[thread overview]
Message-ID: <4D80B6D1.4020201@us.ibm.com> (raw)
In-Reply-To: <AANLkTim0Rm-aKD0+cY31qzu8ONL6WMZJDj5iMfocUUqT@mail.gmail.com>

On 03/16/2011 04:20 AM, Stefan Hajnoczi wrote:
> On Tue, Mar 15, 2011 at 1:13 PM, Anthony Liguori<aliguori@us.ibm.com>  wrote:
>> Why even bothering signaling for completion with the virtio-9p threadpool?
>>
>> There's no sane guest that's going to poll on virtio-9p completion with
>> interrupts disabled and no timer.  Once we enable the I/O thread by default,
>> it won't even be necessary for the paio layer.
> It's not just about preventing livelock under extreme cases.  If you
> omit the signal then !CONFIG_IOTHREAD builds will see increased
> latency because virtfs request completion will piggy-back on other
> events that *do* interrupt the vcpu.

But realistically, the timer is firing at a high enough frequency that I 
doubt you'd even observe the latency.

There's an easy solution here, just do some sniff testing to see if you 
can tell the difference.  I bet you can't.

>    I'm no fan of !CONFIG_IOTHREAD
> but skipping signals is currently bad practice and will continue to be
> until CONFIG_IOTHREAD is removed entirely.
>
> The proper solution would be a thin abstraction for thread-safe
> notification that compiles out signals when CONFIG_IOTHREAD is used.
> Then we have one place in QEMU that does signalling correctly and we
> can optimize it or remove CONFIG_IOTHREAD completely without having
> the burden of duplicating this code in several places.

We have probably 5 different ways to wake up a CPU.  I don't think we 
should add a new one just for this.

!CONFIG_IOTHREAD needs to go away in the very near future.  I'd rather 
focus on that.

Regards,

Anthony Liguori

> Stefan

  reply	other threads:[~2011-03-16 13:10 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-15 10:34 [Qemu-devel] [v1 PATCH 0/3]: Use GLib threadpool in 9pfs Arun R Bharadwaj
2011-03-15 10:36 ` [Qemu-devel] [v1 PATCH 1/3]: Move the paio_signal_handler to a generic location Arun R Bharadwaj
2011-03-15 11:38   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-15 15:27     ` Arun R Bharadwaj
2011-03-15 10:38 ` [Qemu-devel] [v1 PATCH 2/3]: Helper routines to use GLib threadpool infrastructure in 9pfs Arun R Bharadwaj
2011-03-15 11:45   ` Harsh Bora
2011-03-15 15:30     ` Arun R Bharadwaj
2011-03-15 13:13   ` [Qemu-devel] " Anthony Liguori
2011-03-15 15:33     ` Arun R Bharadwaj
2011-03-16  9:20     ` Stefan Hajnoczi
2011-03-16 13:10       ` Anthony Liguori [this message]
2011-03-16 14:20         ` Venkateswararao Jujjuri (JV)
2011-03-16 17:03           ` Stefan Hajnoczi
2011-03-15 10:39 ` [Qemu-devel] [v1 PATCH 3/3]: Convert v9fs_stat to threaded model Arun R Bharadwaj
2011-03-16 10:23   ` [Qemu-devel] " Stefan Hajnoczi
2011-03-16 14:33     ` Venkateswararao Jujjuri (JV)
2011-03-16 17:10       ` Stefan Hajnoczi
2011-03-17  4:26         ` Venkateswararao Jujjuri (JV)
2011-03-17  7:19           ` Stefan Hajnoczi

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=4D80B6D1.4020201@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=arun@linux.vnet.ibm.com \
    --cc=jvrao@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.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 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.