On Thu, May 01, 2008 at 12:34:11PM -0700, Mika Borner wrote:
> > Change your program to something like:
> >
> > syscall::setcontext:entry
> > /execname == "mongrel_rails"/
> > {
> > @[ustack()] = count();
> > }
>
> I did, an the topmost entries are below. I'm not a programmer, but I guess it
> calls a lot of subroutines.
>
> Can the setcontext syscall be avoided somehow, by optimization of program
> code?
>
> Thanks anyway
> Mika
>
> libc.so.1`__getcontext+0xb
> libruby.so.1`rb_yield+0x16
And the winner is ... co-routines.
I'm glancing at the code for rb_yield() and basically Ruby has co-routines
and I see some rather complex #defines around whether this should use
setjmp/longjmp or setcontext()/getcontext() depending on OS and compiler.
Clearly from your DTrace experiment, your Solaris version is ending up
with the context-based implementation, and that is going to be massively
more expensive (and likely unnecessary). This is something I will point
out to the Solaris ruby people and not sure if Jason or others already have.
Basically setjmp/longjmp are just inline assembly, whereas the context
stuff is a system call that restores not only your stack pointer but also
a complete register set, signal masks, floating-point state, and about
a hundred other things. Much of that is entirely unnecessary for a co-routine
implementation because you're not changing signal masks and so forth.
Whether you need the rest depends on how the surrounding code is written.
If nothing else, one immediate optimization I see is that Ruby's context
code doesn't touch uc_flags -- it could at minimum clear out the bits
for things it doesn't need to change. This will save some work in
the kernel, but not the copyin() and the system calls.
We'll need to get in touch with the Ruby VM team and figure out whether
indeed the context code is necessary on Solaris etc. But you have found
something very interesting.
-Mike
--
Mike Shapiro, Sun Microsystems Fishworks. blogs.sun.com/mws/
_______________________________________________
dtrace-discuss mailing list
[email protected]
