Re: [Qemu-devel] [PATCH 0/3] New sigaltstack method for coroutine

[Alex Barcelo]

On Tue, Feb 14, 2012 at 09:33, Stefan Hajnoczi <address@hidden> wrote:
> On Mon, Feb 13, 2012 at 04:11:15PM +0100, Alex Barcelo wrote:
>> This new implementation... well, it seems to work (I have done an
>> ubuntu installation with a cdrom and a qcow drive, which seems to use
>> quite a lot of coroutines). Of course I have done the coroutine-test
>> and it was OK. But... I wasn't confident enough to propose it as a
>> "mature alternative". And I don't have any performance benchmark,
>> which would be interesting. So, I thought that the better option would
>> be to send this patch to the developers as an alternative to ucontext.
>
> As a starting point, I suggest looking at
> test-coroutine.c:perf_lifecycle().  It's a simple create-and-then-enter
> benchmark which measures the latency of doing this.  I expect you will
> find performance is identical to the ucontext version because the
> coroutine should be pooled and created using sigaltstack only once.
>
> The interesting thing would be to benchmark ucontext coroutine creation
> against sigaltstack.  Even then it may not matter much as long as pooled
> coroutines are used most of the time.

Didn't see the performance mode for test-coroutine. Now a benchmark
test it's easy (it's half-done). The lifecycle is not a good
benchmark, because sigaltstack is only called once. (As you said, the
timing change in less than 1%).

I thought that it would be interesting to add a performance test for
nesting (which can be coroutine creation intensive). So I did it. I
will send as a patch, is simple but it works for this.

The preliminary results are:
ucontext (traditional) method:
MSG: Nesting 1000000 iterations of 100000 depth each: 0.452988 s

sigaltstack (new) method:
MSG: Nesting 1000000 iterations of 100000 depth each: 0.689649 s

The sigaltstack is worse (well, it doesn't surprise me, it's more
complicated and does more jumps and is a code flow more erratic). But
a loss in efficiency in coroutines should not be important (how many
coroutines are created in a typical qemu-system execution? I'm
thinking "one"). Also as you said ;) pooled coroutines are used most
of the time, in real qemu-system execution.

tl,dr; the longjmps are the same and equally good (or bad) either way,
so performance won't really aknowledge the change. Will it?