From owner-freebsd-dtrace@FreeBSD.ORG Fri Oct 25 17:51:53 2013 Return-Path: Delivered-To: dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0425CF46; Fri, 25 Oct 2013 17:51:53 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A7F2026DC; Fri, 25 Oct 2013 17:51:52 +0000 (UTC) Received: by mail-qe0-f51.google.com with SMTP id q19so2574012qeb.38 for ; Fri, 25 Oct 2013 10:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=AsK/EIVvKCUQj3vmHSXtTrbgtl4kZlX5CRxloeWGhag=; b=AczjwDZNk1bTCJ4bO5HKRSJz/tvYraFVFf9oruXEOVkIsEO/byhq2oY/EXipGoMeVj inbVQABFA420mN7ieeNCFnPzzo/92ZD2/kFxg+h86qJYcdIm721pCSl0hRFBdl2nATab ziGcbaasB6X8vPJvLUA2CHorvIBZUKWUXhT0LKt0e5QngiGmF6SknexC4X9mMgdVcioN okzadhT8gGqJHf1E64vW/tBICa+LH3tzMGvnjcTNxHwTPEDv6D6iw2+4/bnZ9n4bBlsr titWJ/vwQCX5Vow0PaiRCJXYMJ3z6SH2pi7a9JEwhlQA3AF/GiKfkyyF+WLP0xCIqYUk 0YUQ== X-Received: by 10.224.44.1 with SMTP id y1mr12991370qae.35.1382723511711; Fri, 25 Oct 2013 10:51:51 -0700 (PDT) Received: from charmander (mail1.sandvine.com. [64.7.137.162]) by mx.google.com with ESMTPSA id fx6sm15440220qeb.1.2013.10.25.10.51.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Oct 2013 10:51:49 -0700 (PDT) Sender: Mark Johnston Date: Fri, 25 Oct 2013 13:51:47 -0400 From: Mark Johnston To: Andriy Gapon Subject: Re: "unstable" sdt probes Message-ID: <20131025175147.GB1906@charmander> References: <5268F461.7080504@FreeBSD.org> <20131024161620.GA1710@charmander> <526A9CB5.2050207@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526A9CB5.2050207@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) 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 17:51:53 -0000 On Fri, Oct 25, 2013 at 07:30:45PM +0300, Andriy Gapon wrote: > 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. Ok, I'll try to do some of that stuff this weekend. :) > > 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. 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.