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>