From: Peter Lieven <pl@kamp.de>
To: Paolo Bonzini <pbonzini@redhat.com>,
ming.lei@canonical.com, Kevin Wolf <kwolf@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [RFC PATCH 3/3] qemu-coroutine: use a ring per thread for the pool
Date: Fri, 28 Nov 2014 11:37:27 +0100 [thread overview]
Message-ID: <54785067.60905@kamp.de> (raw)
In-Reply-To: <54784E55.6060405@redhat.com>
Am 28.11.2014 um 11:28 schrieb Paolo Bonzini:
>
> On 28/11/2014 09:13, Peter Lieven wrote:
>> Am 27.11.2014 um 17:40 schrieb Paolo Bonzini:
>>> On 27/11/2014 11:27, Peter Lieven wrote:
>>>> +static __thread struct CoRoutinePool {
>>>> + Coroutine *ptrs[POOL_MAX_SIZE];
>>>> + unsigned int size;
>>>> + unsigned int nextfree;
>>>> +} CoPool;
>>>>
>>> The per-thread ring unfortunately didn't work well last time it was
>>> tested. Devices that do not use ioeventfd (not just the slow ones, even
>>> decently performing ones like ahci, nvme or megasas) will create the
>>> coroutine in the VCPU thread, and destroy it in the iothread. The
>>> result is that coroutines cannot be reused.
>>>
>>> Can you check if this is still the case?
>> I already tested at least for IDE and for ioeventfd=off. The coroutine
>> is created in the vCPU thread and destroyed in the I/O thread.
>>
>> I also havea more complicated version which sets per therad coroutine pool only
>> for dataplane. Avoiding the lock for dedicated iothreads.
>>
>> For those who want to take a look:
>>
>> https://github.com/plieven/qemu/commit/325bc4ef5c7039337fa785744b145e2bdbb7b62e
> Can you test it against the patch I just sent in Kevin's linux-aio
> coroutine thread?
Was already doing it ;-) At least with test-couroutine.c....
master:
Run operation 40000000 iterations 12.851414 s, 3112K operations/s, 321ns per coroutine
paolo:
Run operation 40000000 iterations 11.951720 s, 3346K operations/s, 298ns per coroutine
plieven/perf_master2:
Run operation 40000000 iterations 9.013785 s, 4437K operations/s, 225ns per coroutine
plieven/perf_master:
Run operation 40000000 iterations 11.072883 s, 3612K operations/s, 276ns per coroutine
However, perf_master and perf_master2 have a regerssion regarding nesting as it seems.
@Kevin: Could that be the reason why they performe bad in some szenarios?
Regarding the bypass that is discussed. If it is not just a benchmark thing but really necessary
for some peoples use cases why not add a new aio mode like "bypass" and use it only then.
If the performance is really needed the user he/she might trade it in for lost features like iothrottling, filters etc.
Peter
next prev parent reply other threads:[~2014-11-28 10:37 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-27 10:27 [Qemu-devel] [RFC PATCH 0/3] qemu-coroutine: use a ring per thread for the pool Peter Lieven
2014-11-27 10:27 ` [Qemu-devel] [RFC PATCH 1/3] Revert "coroutine: make pool size dynamic" Peter Lieven
2014-11-28 12:42 ` Stefan Hajnoczi
2014-11-28 12:45 ` Peter Lieven
2014-11-27 10:27 ` [Qemu-devel] [RFC PATCH 2/3] block/block-backend.c: remove coroutine pool reservation Peter Lieven
2014-11-27 10:27 ` [Qemu-devel] [RFC PATCH 3/3] qemu-coroutine: use a ring per thread for the pool Peter Lieven
2014-11-27 16:40 ` Paolo Bonzini
2014-11-28 8:13 ` Peter Lieven
[not found] ` <54784E55.6060405@redhat.com>
2014-11-28 10:37 ` Peter Lieven [this message]
2014-11-28 11:14 ` Paolo Bonzini
2014-11-28 11:21 ` Peter Lieven
2014-11-28 11:23 ` Paolo Bonzini
2014-11-28 11:27 ` Peter Lieven
2014-11-28 11:32 ` Peter Lieven
2014-11-28 11:46 ` Peter Lieven
2014-11-28 12:26 ` Paolo Bonzini
2014-11-28 12:39 ` Peter Lieven
2014-11-28 12:45 ` Paolo Bonzini
2014-11-28 12:49 ` Peter Lieven
2014-11-28 12:56 ` Paolo Bonzini
2014-11-28 13:17 ` Peter Lieven
2014-11-28 14:17 ` Paolo Bonzini
2014-11-28 20:11 ` Peter Lieven
2014-11-28 13:13 ` Peter Lieven
2014-11-28 12:21 ` Paolo Bonzini
2014-11-28 12:26 ` Peter Lieven
2014-11-28 12:40 ` 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=54785067.60905@kamp.de \
--to=pl@kamp.de \
--cc=armbru@redhat.com \
--cc=kwolf@redhat.com \
--cc=ming.lei@canonical.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.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.