From owner-freebsd-dtrace@FreeBSD.ORG Fri Oct 25 16:31:50 2013 Return-Path: Delivered-To: dtrace@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 78719BE8; Fri, 25 Oct 2013 16:31:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 7ED84223C; Fri, 25 Oct 2013 16:31:49 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA17364; Fri, 25 Oct 2013 19:31:42 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1VZkIX-000Aeh-SG; Fri, 25 Oct 2013 19:31:42 +0300 Message-ID: <526A9CB5.2050207@FreeBSD.org> Date: Fri, 25 Oct 2013 19:30:45 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: Mark Johnston Subject: Re: "unstable" sdt probes References: <5268F461.7080504@FreeBSD.org> <20131024161620.GA1710@charmander> In-Reply-To: <20131024161620.GA1710@charmander> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dtrace@FreeBSD.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 16:31:50 -0000 on 24/10/2013 19:16 Mark Johnston said the following: > On Thu, Oct 24, 2013 at 01:20:17PM +0300, Andriy Gapon wrote: >> >> Can our SDT (for kernel) implementation support probes with unspecified types >> for arguments? >> I would like to get DTRACE_PROBE*() which can be found in the code with >> OpenSolaris origins (e.g. ZFS) to work. With minimal efforts :-) > > Hm, it looks like illumos uses the first argument to DTRACE_PROBE* to > specify both the provider name and probe name; if no provider name is > given (based on a lookup in a table in sdt_subr.c), a default "sdt" > provider is used. It looks like this is what's happening for the ZFS > probes. > > I'd suggest something like the following: > - to kern_sdt.c, add > > SDT_PROVIDER_DEFINE(sdt); > > - add DTRACE_PROBE* macros to sdt.h which invoke SDT_PROBE* with the sdt > provider, i.e. something like > > #define DTRACE_PROBE1(name, type, arg) \ > SDT_PROBE1(sdt, , , name, arg) > > - add a FreeBSD-only zfs_dtrace.c which contains the SDT_PROBE_DEFINE* > invocations for the ZFS probes. You can define the types there, or not > (using an empty string or NULL should work, I'm not sure). > > This won't work for illumos code where the probes specify a provider, > but I think that's ok. I can do the first two steps if you agree with > this approach. I don't have any way to test the ZFS probes at the > moment, but I guess I can provide a zfs_dtrace.c too if you (or anyone > else) can test. Mark, thank you for the ideas! The approach sounds fine to me. I plan to have some time to work on this next week. I will definitely be able to test things and maybe even develop something. So, thank you again. 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. 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. -- Andriy Gapon