All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [PATCH v2] posix-aio-compat: fix latency issues
Date: Sun, 28 Aug 2011 11:09:03 +0300	[thread overview]
Message-ID: <4E59F79F.1030504@redhat.com> (raw)
In-Reply-To: <4E53B4C9.3070906@siemens.com>

On 08/23/2011 05:10 PM, Jan Kiszka wrote:
> On 2011-08-23 16:02, Anthony Liguori wrote:
> >  On 08/23/2011 08:02 AM, Jan Kiszka wrote:
> >>  On 2011-08-23 14:40, Anthony Liguori wrote:
> >>>  You should be able to just use an eventfd or pipe.
> >>>
> >>>  Better yet, we should look at using GThreadPool to replace posix-aio-compat.
> >>
> >>  When interacting with the thread pool is part of some time-critical path
> >>  (easily possible with a real-time Linux guest), general-purpose
> >>  implementations like what glib offers are typically out of the game.
> >>  They do not provide sufficient customizability, specifically control
> >>  over their internal synchronization and allocation policies. That
> >>  applies to the other rather primitive glib threading and locking
> >>  services as well.
> >
> >  We can certainly enhance glib.  glib is a cross platform library.  I
>
> Do you want to carry forked glib bits in QEMU?

We can make real-time depend on a newer glib version.

>
> >  don't see a compelling reason to invent a new cross platform library
> >  just for QEMU especially if the justification is future features, not
> >  current features.
>
> Tweaking affinity of aio threads is already a current requirement.
>
> And we already have a working threading and locking system. One that is
> growing beyond glib's level of support quickly (think of RCU).
>

glib will have to support RCU as well.  But for this topic, I agree with 
you for now.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

WARNING: multiple messages have this Message-ID (diff)
From: Avi Kivity <avi@redhat.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Stefan Hajnoczi <stefanha@gmail.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH v2] posix-aio-compat: fix latency issues
Date: Sun, 28 Aug 2011 11:09:03 +0300	[thread overview]
Message-ID: <4E59F79F.1030504@redhat.com> (raw)
In-Reply-To: <4E53B4C9.3070906@siemens.com>

On 08/23/2011 05:10 PM, Jan Kiszka wrote:
> On 2011-08-23 16:02, Anthony Liguori wrote:
> >  On 08/23/2011 08:02 AM, Jan Kiszka wrote:
> >>  On 2011-08-23 14:40, Anthony Liguori wrote:
> >>>  You should be able to just use an eventfd or pipe.
> >>>
> >>>  Better yet, we should look at using GThreadPool to replace posix-aio-compat.
> >>
> >>  When interacting with the thread pool is part of some time-critical path
> >>  (easily possible with a real-time Linux guest), general-purpose
> >>  implementations like what glib offers are typically out of the game.
> >>  They do not provide sufficient customizability, specifically control
> >>  over their internal synchronization and allocation policies. That
> >>  applies to the other rather primitive glib threading and locking
> >>  services as well.
> >
> >  We can certainly enhance glib.  glib is a cross platform library.  I
>
> Do you want to carry forked glib bits in QEMU?

We can make real-time depend on a newer glib version.

>
> >  don't see a compelling reason to invent a new cross platform library
> >  just for QEMU especially if the justification is future features, not
> >  current features.
>
> Tweaking affinity of aio threads is already a current requirement.
>
> And we already have a working threading and locking system. One that is
> growing beyond glib's level of support quickly (think of RCU).
>

glib will have to support RCU as well.  But for this topic, I agree with 
you for now.

-- 
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

  reply	other threads:[~2011-08-28  8:09 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-14  4:04 [PATCH v2] posix-aio-compat: fix latency issues Avi Kivity
2011-08-14  4:04 ` [Qemu-devel] " Avi Kivity
2011-08-22 17:22 ` Kevin Wolf
2011-08-22 17:22   ` [Qemu-devel] " Kevin Wolf
2011-08-22 17:29 ` Jan Kiszka
2011-08-22 17:29   ` [Qemu-devel] " Jan Kiszka
2011-08-23 11:01   ` Stefan Hajnoczi
2011-08-23 11:01     ` [Qemu-devel] " Stefan Hajnoczi
2011-08-23 12:40     ` Anthony Liguori
2011-08-23 12:40       ` Anthony Liguori
2011-08-23 13:02       ` Jan Kiszka
2011-08-23 13:02         ` Jan Kiszka
2011-08-23 14:02         ` Anthony Liguori
2011-08-23 14:10           ` Jan Kiszka
2011-08-28  8:09             ` Avi Kivity [this message]
2011-08-28  8:09               ` Avi Kivity

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=4E59F79F.1030504@redhat.com \
    --to=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.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.