Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Jun 2012 13:04:01 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Dag-Erling Sm??rgrav <des@des.no>
Cc:        John Baldwin <jhb@FreeBSD.org>, freebsd-arch@FreeBSD.org
Subject:   Re: Fast vs slow syscalls (Re: Fwd: [RFC] Kernel shared variables)
Message-ID:  <20120607100401.GW85127@deviant.kiev.zoral.com.ua>
In-Reply-To: <86sje7sf31.fsf@ds4.des.no>
References:  <CACfq090r1tWhuDkxdSZ24fwafbVKU0yduu1yV2%2BoYo%2BwwT4ipA@mail.gmail.com> <201206051008.29568.jhb@freebsd.org> <86haupvk4a.fsf@ds4.des.no> <201206051222.12627.jhb@freebsd.org> <20120605171446.GA28387@onelab2.iet.unipi.it> <20120606040931.F1050@besplex.bde.org> <864nqovoek.fsf@ds4.des.no> <20120607064951.C1106@besplex.bde.org> <86sje7sf31.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help

--PoKbPPFu8MuDl6RC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jun 07, 2012 at 10:26:10AM +0200, Dag-Erling Sm??rgrav wrote:
> Bruce Evans <brde@optusnet.com.au> writes:
> > Now 2.44 nsec/call makes sense, but you really should add some volatiles
> > here to ensure that getpid() is not optimized away.
>=20
> As you can see from the disassembly I provided, it isn't.
>=20
> > SO it loops OK, but we can't see what getpid() does.  It must not be
> > doing much.
>=20
> Umm, yes, that's the whole point of this conversation.  Linux's getpid()
> is not a syscall, but a library function that returns a constant from a
> page shared by the kernel.
>=20
> > 5.4104 nsec/call for gettimeofday() is impossible if there is any
> > rdtsc() hardware call or much layering.
>=20
> It's gettimeofday(0, 0), actually, so it doesn't need to read the clock.
> If I pass a struct timeval as the first argument - so it *does* need to
> read the clock - it's a little bit slower but still faster than an
> actual system call.  Here's another run that demonstrates this - a
> little bit slower than previous runs because I have other processes
> running:
>=20
> getpid(): 10,000,000 iterations in 30,377 us
> gettimeofday(0, 0): 10,000,000 iterations in 55,571 us
> gettimeofday(&tv, 0): 10,000,000 iterations in 302,634 us
So this timing seems to be approximately same by the order of magnitude
as the times I get for the patch, around 25 vs. 30ns/per gettimeofday()
call.

Linux seems slower probably due to slower CPU ? Mine is 3.4Ghz, while
des used 3.1Ghz for Linux box.

> kill(pid, 0): 10,000,000 iterations in 1,291,793 us
>=20
> I can't test a static build since RHEL6 does not provide a static libc.
>=20
> DES
> --=20
> Dag-Erling Sm??rgrav - des@des.no

--PoKbPPFu8MuDl6RC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (FreeBSD)

iEYEARECAAYFAk/QfJEACgkQC3+MBN1Mb4itsgCgsxTeKDTcDUfT3Q8hK0aYFBDs
0+sAoMzkk9S8GR9ivMLh2+70M0nWjqOz
=tk9Z
-----END PGP SIGNATURE-----

--PoKbPPFu8MuDl6RC--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120607100401.GW85127>