Date: Fri, 25 Oct 2013 14:05:20 -0400 From: George Neville-Neil <gnn@neville-neil.com> To: Mark Johnston <markj@freebsd.org> Cc: dtrace@FreeBSD.org, Andriy Gapon <avg@FreeBSD.org> Subject: Re: "unstable" sdt probes Message-ID: <4B39604C-C678-43A1-9EFD-D1D7DE69CF02@neville-neil.com> In-Reply-To: <20131025175147.GB1906@charmander> References: <5268F461.7080504@FreeBSD.org> <20131024161620.GA1710@charmander> <526A9CB5.2050207@FreeBSD.org> <20131025175147.GB1906@charmander>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_5ED9664E-A781-43F5-9A39-E92595CF34BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 25, 2013, at 13:51 , Mark Johnston <markj@freebsd.org> wrote: >>=20 >> BTW, I've been pondering an idea of reimplementing how the SDT probes = get >> called. In FreeBSD we have a special hook function pointer that we = check for >> not being NULL and then make a function call. >> In illumos they compile the code with an unconditional function call. = This way >> the probe parameters are placed into the proper registers (or stack = locations). >> But during run-time linking the call instructions are replaced with = series of >> 1-byte NOP instructions (5 x 0x90 for amd64). When a probe gets = activated then >> the first of those NOPs gets replaced with 0xf0 (lock prefix), which = results in >> an invalid instruction (and that happens atomically). So, that = allows for the >> SDT hook to be invoked via the trap handler. >>=20 >> So, I think that that results in less overhead for inactive probes, = but probably >> in more overhead for active probes. There is a trade off, but I = believe that >> less overhead for inactive probes is preferred. >=20 > I'd like to find a good way of quantifying the overhead of the current > approach when probes are disabled. Do you have any suggestions? One > thing I'd like to try is just doing a TCP bulk transfer to localhost, > since that'll trip the ip and tcp probes for each packet, and then > just measure throughput with the current implementation and with the > approach used in illumos. > _ Are you wanting to quantify just the workload involved with the probes = being on and off? If so, you want something simpler, and lower overhead than a TCP connection. Perhaps measuring fork() (not exec) with unixbench. I gather you=92re going to do this with hwpmc? Best, George --Apple-Mail=_5ED9664E-A781-43F5-9A39-E92595CF34BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlJqsuAACgkQYdh2wUQKM9IEoACgnaTjSwigUa4G/kJ34kiIaQji Y/oAoJe6r1LS/Mg92LKy6Im1FQMHBNiH =QYel -----END PGP SIGNATURE----- --Apple-Mail=_5ED9664E-A781-43F5-9A39-E92595CF34BF--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B39604C-C678-43A1-9EFD-D1D7DE69CF02>