Date: Tue, 26 Feb 2002 20:29:46 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: Bob Van Valzah <Bob@Talarian.Com> Cc: Robert Watson <rwatson@FreeBSD.ORG>, Jorge Aldana <jorge@salk.edu>, Garance A Drosihn <drosih@rpi.edu>, smp@FreeBSD.ORG Subject: Re: Performance vs. Stable Message-ID: <3C7C60BA.3FBDB9A0@mindspring.com> References: <Pine.NEB.3.96L.1020226224905.38595O-100000@fledge.watson.org> <1014782526.15635.22.camel@Relent.Bob.WhiteBarn.Com>
index | next in thread | previous in thread | raw e-mail
Bob Van Valzah wrote:
> On Tue, 2002-02-26 at 21:50, Robert Watson wrote:
> > What is the 'null system call'?
>
> It looks like Larry was a bit fast and loose with language in writing
> the summary report (maybe to make it fit in the header). It appears to
> be the time needed to write one byte to /dev/null. I don't see why
> that's any more "null" than say, getpid().
It makes you cross the user/kernel boundary.
Smart systems implement things that never change, like
getpid, as:
static struct _saved {
pid_t s_pid;
} cached_state = {
-1
};
pid_t
getpid(void)
{
pid_t rv = cached_state.s_pid;
if( s_pid == -1)
rv = system_getpid();
return rv;
}
...
fork()
...
cached_state.s_pid = -1; /* reset cache on fork */
Thus such calls have zero system call overhead.
Similar shortcuts can be had for other read-values, such as
getgid, getgroups, etc., etc. (hacks required in the set
call wrapper for fork, etc., obviously).
Using a write of /dev/null is an attempt to work around this;
of course, you could special case that, as well, in user space,
but it'd be more work than Larry thinks most people will go to
to cheat on the benchmark (Hi Larry! 8-)).
-- Terry
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C7C60BA.3FBDB9A0>