Date: Fri, 11 Jun 1999 19:51:30 -0600 From: Wes Peters <wes@softweyr.com> To: "David E. Cross" <crossd@cs.rpi.edu> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: High syscall overhead? Message-ID: <3761BD22.782508D3@softweyr.com> References: <199906111440.KAA70517@cs.rpi.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
"David E. Cross" wrote:
>
> Just doing some performance testing and I noticed something rather
> disturbing....
>
> Here is the test program:
> int main (void)
> {
> int count=0;
> for(count=0;count <10000000;++count)
> getppid();
>
> return 0;
> }
>
> The time on linux for this program is ~5 seconds (linux "time" reports 3.x, but
> a wall clock clearly shows 5.x, go fig). FreeBSD reports 18.x seconds?!. I
> have a dual processor system and decided to parallel run them... it took
> 52!?! seconds, linux on the same was again about 5. Looking through the
> exception.s it appears that on entry to the kernel an MP lock is obtained...
> I thought we had splX(); to protect concurancy in the kernel.
>
> I am just curious what's the story with this. On some of my other tests it is
> clear that FreeBSD is handling concurancy much better than linux (by an equal
> factor actually, and on "real" tasks like real I/O handling).
My PII/300 reports:
wes@homer$ time ./a.out
real 0m12.490s
user 0m5.898s
sys 0m6.455s
Let's see, that's:
wes@homer$ bc
bc 1.04
Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc.
This is free software with ABSOLUTELY NO WARRANTY.
For details type `warranty'.
10000000/1249
8006
1000000000/1249
800640
800,000 syscalls/sec and you're complaining? Heh. ;^)
I suspect this is one of those "optimizations" where the Linux syscall
mechanism doesn't actually enter the kernel, since the parent pid is
probably stored in the equivalent of the proc struct. True to the
Linux "every cycle is precious" ethic, these optimizations are great
for looking good on meaningless benchmarks like this one, and make no
difference at all in "real life."
Try a more meaningful benchmark, one that actually does something in
the kernel before returning, and see how they do. Try calling kill
or socket/close a few hundred thousand times and see how they do.
--
"Where am I, and what am I doing in this handbasket?"
Wes Peters Softweyr LLC
http://www.softweyr.com/~softweyr wes@softweyr.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3761BD22.782508D3>