[9fans] too many system calls.

[9fans] too many system calls.

[ron minnich]

Glibc /bin/date on Linux runs around 140 system calls. A quick pass
with ratrace shows that plan 9 /bin/date has 10.

The conclusion is clear: plan 9 date has way too much overhead. It's
1/14 the number of system calls of Glibc; why's it so big?

A quick pass on getpid() fixes the problem:

#include	<u.h>
#include	<libc.h>
#include	<tos.h>

int
getpid(void)
{
	return _tos->pid;
}

Now we're down to seven system calls. 1/20 of glibc. Much better! :-)

ron

Re: [9fans] too many system calls.

[Akshat Kumar]

Is ratrace usable on native Plan 9 (I understand it's in use on 9vx
thus far)? I don't see a /proc/n/syscall file for any of my processes;
is there some kernel patch for this?


Thanks,
ak

On Fri, Sep 3, 2010 at 10:14 PM, ron minnich <rminnich@gmail.com> wrote:
> Glibc /bin/date on Linux runs around 140 system calls. A quick pass
> with ratrace shows that plan 9 /bin/date has 10.
>
> The conclusion is clear: plan 9 date has way too much overhead. It's
> 1/14 the number of system calls of Glibc; why's it so big?
>
> A quick pass on getpid() fixes the problem:
>
> #include        <u.h>
> #include        <libc.h>
> #include        <tos.h>
>
> int
> getpid(void)
> {
>        return _tos->pid;
> }
>
> Now we're down to seven system calls. 1/20 of glibc. Much better! :-)
>
> ron
>
>

Re: [9fans] too many system calls.

[erik quanstrom]

On Sat Sep  4 03:59:16 EDT 2010, akumar@mail.nanosouffle.net wrote:
> Is ratrace usable on native Plan 9 (I understand it's in use on 9vx
> thus far)? I don't see a /proc/n/syscall file for any of my processes;
> is there some kernel patch for this?

acid is perfectly capabible of doing this.
see the man page on acid(1) which covers
the truss library.

- erik

Re: [9fans] too many system calls.

[ron minnich]

On Sat, Sep 4, 2010 at 12:58 AM, Akshat Kumar
<akumar@mail.nanosouffle.net> wrote:
> Is ratrace usable on native Plan 9 (I understand it's in use on 9vx
> thus far)? I don't see a /proc/n/syscall file for any of my processes;
> is there some kernel patch for this?

One could take the modified version of my syscall tracing code that
jmk put into the 9k kernel and put that into the regular plan 9
kernel. He did a very nice job of making it almost completely live in
port and it's a good lesson in getting it right, worth looking at.
Paper submitted to iwp9 ...

I don't run any systems in my lab with the 9 kernel any more so I have
not been motivated to make the change myself. I have used ratrace
heavily on Blue Gene for debugging, and it's been much easier to use
than Acid in that environment.

I still use acid truss at times, when ratrace is not available, but I
find ratrace far more useful when it is there. Actually, I now realize
it's worse than that: I've stopped using systems that don't have
ratrace because I find debugging problems without some sort of syscall
trace to be too time-consuming. Note that it's easy to drop ratrace
into scripts and that's handy.

The getpid change I described here is now in my bitbucket repo
https://rminnich@bitbucket.org/rminnich/sysfromiso

That code builds and works on 9vx. I know there were some issues a few
weeks ago with the builds which is why I mention it here. You should
be able to build that userland code and run it on any Plan 9 system. I
have built that tree to support arm, for example.

The vx32 I am using is a combo of changes from yiyu and me and is
found at https://rminnich@bitbucket.org/rminnich/vx32

ron