From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12175 invoked by alias); 14 Jul 2008 22:03:12 -0000 Received: (qmail 12166 invoked by uid 22791); 14 Jul 2008 22:03:11 -0000 X-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_73,SPF_PASS X-Spam-Check-By: sourceware.org Received: from accolon.hansenpartnership.com (HELO accolon.hansenpartnership.com) (76.243.235.52) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jul 2008 22:02:46 +0000 Received: from localhost (localhost [127.0.0.1]) by accolon.hansenpartnership.com (Postfix) with ESMTP id BE68F8BDA; Mon, 14 Jul 2008 17:02:42 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1216072962; bh=aWw0NFp6FD8tyvih+f8pSHSLVGltkACn/X/HNTgKc9 E=; l=2575; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=j3/xrporhMX8Hjxt7nBwWIdLKTN+RZFbT0bJ4 02SS9F0y4YDr51lrPYRQYA0zKl4WwIpHaHaTT5wprCVuSLwO4ERJrl64iQpLp+XeW77 5ZPV8pBSyr1J8L3VXWQCGkTzQHhinDf2TeMS0dczxSh7vmfi8Oe2hS15SXyWfdRCh7o = Received: from accolon.hansenpartnership.com ([127.0.0.1]) by localhost (redscar.int.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF+-9hn4xe7i; Mon, 14 Jul 2008 17:02:41 -0500 (CDT) Received: from [153.66.150.222] (mulgrave-w.int.hansenpartnership.com [153.66.150.222]) by accolon.hansenpartnership.com (Postfix) with ESMTP id E4E1C8033; Mon, 14 Jul 2008 17:02:40 -0500 (CDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=2007; t=1216072961; bh=aWw0NFp6FD8tyvih+f8pSHSLVGltkACn/X/HNTgKc9 E=; l=2575; h=Subject:From:To:Cc:In-Reply-To:References: Content-Type:Date:Message-Id:Mime-Version: Content-Transfer-Encoding; b=VohgX+wLtw0CrLq6A/iH9lKU4GfmwvlyWo+qg ldaCWIB+2NY8ktSyhS7KrpO+ys4bQyJEpgiSo4krNROPoJ7yBqg4lim2up9pT3E/sDo PKpcmO6PtmrGjD1KfSuRu2DuxPoo8KHtdv+kCrtLOM5kfC8dIoOdvxkA3AAlc6P3E5w = Subject: Re: [PATCH] simple dprobe like markers for the kernel From: James Bottomley To: Masami Hiramatsu Cc: Theodore Tso , "Frank Ch. Eigler" , linux-kernel , systemtap@sourceware.org, Mathieu Desnoyers In-Reply-To: <487B7E37.9050600@redhat.com> References: <1215638551.3444.39.camel__22002.9595810503$1215638656$gmane$org@localhost.localdomain> <1215697794.3353.5.camel@localhost.localdomain> <20080710142208.GC1213@redhat.com> <1215700996.3353.30.camel@localhost.localdomain> <20080710153017.GB25939@mit.edu> <1215886965.3360.16.camel@localhost.localdomain> <487B7E37.9050600@redhat.com> Content-Type: text/plain Date: Mon, 14 Jul 2008 22:03:00 -0000 Message-Id: <1216072960.3378.65.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2008-q3/txt/msg00172.txt.bz2 On Mon, 2008-07-14 at 12:26 -0400, Masami Hiramatsu wrote: > Hi James, > > James Bottomley wrote: > > This is just an incremental update based on feedback. The most > > significant was that making the marker a compiler barrier will free the > > inserter from worrying about the mark sliding around changes to named > > variables (and thus having to worry about this in placement) at > > practically zero optimisation cost. I also updated the code to drop and > > asm section instead of using the static variable scheme. I also added > > documentation and made the module loader ignore them (since modules > > don't go through the vmlinux.lds transformations). > > I'm very interested in your approach. > > IMHO, as Aoki investigated, the overhead of markers is not so big > unless we put a lot of them into kernel. That's the case which I started from. The point is that if passive markers have a cost, we have to be very careful about placing them to avoid the cost adding up. > And from "active" > overhead point of view, it takes less than tens of nano-seconds, > while kprobes takes hundreds of nano-seconds. Kprobe also has a > limitation of probable points, it can't probe "__kprobes" marked > functions. So, original markers still has advantages. Yes ... the zero impact markers are completely dependent on the kprobes overhead for activation ... on the other hand, one of the vendor complaints is cost of activation of kprobes, so it's nicely tied into solving that particular problem. > However, your approach is also useful, especially for embedding > thousands of markers in kernel or drivers. > > So I think it's better to use both of them as the situation demands. Certainly ... as I said to Ted, I'm not planning to replace the current markers, just give a lightweight alternative. > I just have one comment on its name. Since it doesn't trace > anything, so I'd rather like notation() or note_mark() than > trace_simple(). :-) well ... the current markers code uses trace_mark as its base .. I was just trying to fit into that scheme. Also, don't rely on anything in this code yet ... that's why it's an RFC; I'm still playing around with the section formats and the information. After more discussions with people, I'm actually coming to the conclusion that dropping the address of the simple marker might be very useful (in place of file and line). It makes the marker section need relocation, but it would also mean they could be used simply from within the kernel as well. James