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

[Stefan Hajnoczi]

On Mon, Feb 13, 2012 at 04:11:15PM +0100, Alex Barcelo wrote:
> On Mon, Feb 13, 2012 at 15:51, Peter Maydell <address@hidden> wrote:
> > On 13 February 2012 14:42, Alex Barcelo <address@hidden> wrote:
> >> This series of patches implements coroutines method with
> >> sigaltstack.
> >>
> >> The flow of creation and management of the coroutines is
> >> quite similar to the coroutine-ucontext.c. The way to use
> >> sigaltstack to achieve the needed stack manipulation is
> >> done in a way quite similar to the GNU Portable Threads
> >> (file pth_mctx.c, variant 2).
> >
> > So the obvious question here is why this should be a new
> > coroutine method rather than just replacing the ucontext one.
> 
> Well, you are right. I did this because I needed something for an
> environment which doesn't have ucontext support[1] (and the fallback
> was awful).

I agree that we should aim to have 1 thing that works really well
instead of multiple things that work okay sometimes.

> > The ucontext implementation is problematic because makecontext
> > &co aren't implemented on all platforms (ARM Linux, and I think
> > at least one of the BSDs?). Is this sigaltstack approach
> > workable on a strict superset of the platforms that would
> > be able to use ucontext? Does it have any disadvantages that
> > would mean you wouldn't want to use it as a first choice
> > if you had ucontext?
> 
> 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.

Stefan