All of lore.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <aliguori@us.ibm.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Jan Kiszka <jan.kiszka@siemens.com>,
	Michael Tokarev <mjt@tls.msk.ru>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host
Date: Wed, 09 May 2012 16:36:42 -0500	[thread overview]
Message-ID: <4FAAE36A.1040808@us.ibm.com> (raw)
In-Reply-To: <CAFEAcA_w0Qr0cVryrYkib5Q0Ydw6+QqPQh_siu73sXRVNA0P5w@mail.gmail.com>

On 05/09/2012 04:27 PM, Peter Maydell wrote:
> On 9 May 2012 21:59, Anthony Liguori<aliguori@us.ibm.com>  wrote:
>> On 05/09/2012 03:46 PM, Peter Maydell wrote:
>>> Longer term (ie post 1.1) I'm strongly in favour of kicking
>>> out coroutines, because I think there clearly is no single
>>> solid portable implementation possible. C just isn't designed
>>> to allow them; better not to try to swim against the current.
>
>> Unfortunately, voting for code to be different doesn't actually make it
>> different.
>
> Yeah, I agree with this sentiment...
>
>> If you're volunteering to rewrite the block layer to not require coroutines
>> (either by using a state machine or by using re-entrant threads and fixing
>> any locking issues associated with that) that's wonderful.
>>
>> But we decided to not do synchronous I/O years ago and still haven't removed
>> it all from the tree.  Coroutines got us much closer to getting rid of
>> synchronous I/O.
>
> ...but I would at least like us to take the position that we don't
> introduce *more* users of coroutines.

I think the long term plan has been:

1) replace synchronous I/O users with coroutines + async I/O

2) promote coroutines to threads by introducing fine grain locking.

I don't think avoiding coroutines helps us along this route nor does it help 
eliminate immediate users of coroutines.

I think our best strategy forward is to get rid of async I/O in the blocker 
layer and in devices.  Then I think we should promote coroutines as much as 
possible.

Regards,

Anthony Liguori

>
> -- PMM
>

  reply	other threads:[~2012-05-09 21:36 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-09 19:21 [Qemu-devel] [PATCH 1.1] coroutine: Avoid ucontext usage on i386 Linux host Jan Kiszka
2012-05-09 19:27 ` Michael Tokarev
2012-05-09 19:34   ` Jan Kiszka
2012-05-09 19:48     ` Anthony Liguori
2012-05-09 19:57       ` Jan Kiszka
2012-05-09 20:01         ` Anthony Liguori
2012-05-09 20:11           ` Jan Kiszka
2012-05-09 20:46             ` Peter Maydell
2012-05-09 20:59               ` Anthony Liguori
2012-05-09 21:27                 ` Peter Maydell
2012-05-09 21:36                   ` Anthony Liguori [this message]
2012-05-09 20:56             ` Anthony Liguori
2012-05-09 20:04 ` Michael Tokarev

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=4FAAE36A.1040808@us.ibm.com \
    --to=aliguori@us.ibm.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kwolf@redhat.com \
    --cc=mjt@tls.msk.ru \
    --cc=peter.maydell@linaro.org \
    --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.