This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC] simple dprobe like markers for the kernel
- From: James Bottomley <James dot Bottomley at HansenPartnership dot com>
- To: Theodore Tso <tytso at mit dot edu>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, linux-kernel <linux-kernel at vger dot kernel dot org>, systemtap at sourceware dot org
- Date: Thu, 10 Jul 2008 10:57:17 -0500
- Subject: Re: [RFC] simple dprobe like markers for the kernel
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215705441; bh=+DPdpJbfIfFU8jY6lWCwTcHubBemcMzd4Ck1ro/UEA 8=; l=2328; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=F7nnrq23SduIXWpNhysST8t4yQ748R052paRg 76RtkTdEN058wFEkl5IevO0ie4TlEMJw5jgdoKlVyc0cNEFPIGtw8IcPf9l7imIEduh D2AfAOBaWeU2iXG5ktnq9p+q4SROjRanFE1TZro4YIYVy0pk8BanBwW4DX++axEQajw =
- Dkim-signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1215705438; bh=+DPdpJbfIfFU8jY6lWCwTcHubBemcMzd4Ck1ro/UEA 8=; l=2328; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=a6cxygklS6aU8n8fSPnZp19XDcQMumSy8CgIo s6auCxYjzKrFa6FoA+m7YNa1s6eLF/twTM8GsCErM/OfVkonahJ6uWkCt8gHSpYi74i KWtgy1fIQZlb2AxPpyJtxU+yfuOvhMwqcDJUKGBk5k1b+rSwGkhdY2ChtPVX4vyrROE =
- References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> <y0m1w22qxoj.fsf@ton.toronto.redhat.com> <1215697794.3353.5.camel@localhost.localdomain> <20080710142208.GC1213@redhat.com> <1215700996.3353.30.camel@localhost.localdomain> <20080710153017.GB25939@mit.edu>
On Thu, 2008-07-10 at 11:30 -0400, Theodore Tso wrote:
> On Thu, Jul 10, 2008 at 09:43:16AM -0500, James Bottomley wrote:
> > No ... I'm used to optimisation strangeness. Again, I'm not trying to
> > eliminate it because that would defeat the zero impact purpose. I'm
> > trying to build a system that can be useful without any impact. The
> > consequence is going to be that certain trace points can't be used
> > because of the optimiser, but that's the tradeoff. As long as the
> > people placing the trace points are subject matter experts in the
> > subsystem (and actually using them) everything should be OK.
>
> So as I understand things, your light-weight tracepoints are designed
> for very performance-sensitive code paths where we don't want to
> disturbe the optimization in the deactivated state. In
> non-performance sensitive parts of the kernel, where cycle counting is
> not so important, tracepoints can and probably should still be used.
> So I don't think you were proposing eliminating the current kernel
> markers in favor of this approach, yes?
That's right ... I started from the position that the current markers
were too heavy for an I/O subsystem, but I'm sure they have many other
uses.
> When you said a tool could determine if the tracepoint had gotten
> optimized away, or the variables were no longer present, I assume you
> meant at compile time, right?
Yes and no. Yes because a tool will be able to detect the problems, but
no if you're thinking an actual kernel compile would do it (unless some
tool is designed for this and integrated into the build ... the obvious
tool is systemtap, but that might cause some heartburn).
> So with the right tool built into the
> kbuild infrastructure, if we could simply print warnings when
> tracepoints had gotten optimized away, that would make the your simple
> tracepoints quite safe for general use, I would think.
Yes ... but someone has to come up with the tool. I suppose rebuilding
the line number matrix and finding the variables at the location is easy
mechanical dwarf stuff ... but it will give the kernel build a lot of
external dependencies it didn't have before.
Plus, this level of checking can only be done if dwarf is generated
(i.e. CONFIG_KERNEL_DEBUG_INFO is y).
James