From owner-freebsd-arch@freebsd.org Wed Nov 25 23:23:47 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6C23A36B24 for ; Wed, 25 Nov 2015 23:23:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58B3519B8 for ; Wed, 25 Nov 2015 23:23:47 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by qgec40 with SMTP id c40so43592829qge.2 for ; Wed, 25 Nov 2015 15:23:46 -0800 (PST) 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=b+an/08KLDBip42lT3yPevLGf7qo+lEVJS5whjCmHLQ=; b=IAuywU0KMxwzt1FNOZ3jQfy069rlOaF1bjgJs5uqMnaYls9PoHFD9bveERHcMklLAX Y2mNnSK3UjeaEMzjTYJOx1AaPAyNOH45/j45wmOD82lpZ6hj2O7RGONISul5whRGJJu4 7VmDhRvfOydaz3FXxDSv59tuLWj4nzf+rIf+TQTu2qk+EpKqIu8Ted9gPJFn+CX6u4jZ pSrgGPxWn2DiyhaIoyuFLQMpXQ8ZCswnTnQ9yfaqTBtb1hFOqCVKcP4Fvu3yNJ4srUTc QQsBesGdv+w2pyrlAwjG63PnO5VjcmzHbMFP0gsYrNs1Itsl2eMN5pR+udPCYcMEZTXL Se4w== X-Received: by 10.140.172.3 with SMTP id s3mr45077432qhs.6.1448493826331; Wed, 25 Nov 2015 15:23:46 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-67-182-131-225.hsd1.wa.comcast.net. [67.182.131.225]) by smtp.gmail.com with ESMTPSA id t47sm6233205qgt.28.2015.11.25.15.23.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Nov 2015 15:23:46 -0800 (PST) Sender: Mark Johnston Date: Wed, 25 Nov 2015 15:25:24 -0800 From: Mark Johnston To: Konstantin Belousov Cc: freebsd-arch@FreeBSD.org Subject: Re: zero-cost SDT probes Message-ID: <20151125232524.GB67865@wkstn-mjohnston.west.isilon.com> References: <20151122024542.GA44664@wkstn-mjohnston.west.isilon.com> <20151123113511.GX58629@kib.kiev.ua> <20151125001136.GB70878@wkstn-mjohnston.west.isilon.com> <20151125131533.GB3448@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151125131533.GB3448@kib.kiev.ua> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2015 23:23:47 -0000 On Wed, Nov 25, 2015 at 03:15:33PM +0200, Konstantin Belousov wrote: > On Tue, Nov 24, 2015 at 04:11:36PM -0800, Mark Johnston wrote: > > If I understood correctly, each probe site would require a separate page > > in KVA to be able to enable and disable individual probes in the manner > > that I described in a previous reply. Today, a kernel with lock inlining > > has thousands of probe sites; wouldn't the requirement of allocating KVA > > for each of them be prohibitive on 32-bit architectures? > > Several variations of the approach allow to control each probe site > individually, while still avoiding jumps and reducing the cache consumption. > And, of course, the biggest advantage is avoiding the need to change the > text at runtime. > > E.g., you could have a byte allocated somewhere for each probe, with usual > boolean values true/false for enabled/disabled state. Also, somewhere, > you have two KVA pages allocated, say, starting at address p, the first > page is mapped, the second page is not. The pages are shared between all > probes. Then, the following code sequence would trigger the page fault > only for enabled probe: > movzbl this_probe_enable_byte, %eax > movl (p + PAGE_SIZE - 4)(%eax), %eax > This approach is quite portable and can be expressed in C. > > If expected count of probes is thousands, as you mentioned, then you > would pay only for several KB of memory for enable control bytes. > > Another variant is possible with the use of INTO instruction, which > has relatively low latency when not trapping, according to the Agner > Fog tables. I see. I think this could be made to work, but there's still the complication of passing arguments to the probe. Copying them into some block in curthread is one way to do this, but it seems more expensive than the standard calling convention on amd64 at least.