From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14561 invoked by alias); 30 Oct 2006 14:11:16 -0000 Received: (qmail 14550 invoked by uid 22791); 30 Oct 2006 14:11:15 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,TW_DJ X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 30 Oct 2006 14:11:07 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9UEB5tp004340; Mon, 30 Oct 2006 09:11:05 -0500 Received: from pobox.devel.redhat.com (pobox.devel.redhat.com [10.11.255.8]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9UEB4rP015441; Mon, 30 Oct 2006 09:11:04 -0500 Received: from [10.11.14.52] (vpn-14-52.rdu.redhat.com [10.11.14.52]) by pobox.devel.redhat.com (8.13.1/8.13.1) with ESMTP id k9UEB29R020292; Mon, 30 Oct 2006 09:11:02 -0500 Subject: Re: [PATCH 2/5][djprobe] djprobe core patch From: Ingo Molnar To: Masami Hiramatsu Cc: Keshavamurthy@bambi.jf.intel.com, Anil S , Ananth N Mavinakayanahalli , Prasanna S Panchamukhi , SystemTAP , Satoshi Oshima , Hideo Aoki , Yumiko Sugita In-Reply-To: <454606E0.3050703@hitachi.com> References: <45338593.6090207@hitachi.com> <45373F28.1070305@hitachi.com> <20061027233941.GB10018@bambi.jf.intel.com> <454606E0.3050703@hitachi.com> Content-Type: text/plain Date: Mon, 30 Oct 2006 14:11:00 -0000 Message-Id: <1162217443.15286.14.camel@earth> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 (2.8.1.1-3.fc6) Content-Transfer-Encoding: 7bit Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00278.txt.bz2 On Mon, 2006-10-30 at 23:06 +0900, Masami Hiramatsu wrote: > 1) I thought that should be waste of memory. As you can see, > the djprobe structure doesn't have its kprobe nor instruction > buffer, because it is just an interface structure. Instead of > that, it has an pointer to the djprobe_instance structure which > is true instance of the djprobe. This "instance" has the kprobe > structure and instruction buffer. So, I could keep the djprobe > structure small. > 2) The other reason is from difference of the usage between djprobe > and kprobe. Kprobe users have to ensure that the target address > points to the 1st byte of instruction. On the other hand, djprobe > users additionally have to count the length of the target > instructions, and ensure those instructions are relocatable. > > Therefore, I provided those special interfaces. > > If you never mind that the jump-based-kprobe needs two > kprobe structures per one probe point (one is for the interface, > another is for the instance -- for deferred releasing), I can > integrate these interfaces. I dont think memory overhead is a big issue - API compatibility is important and it will also speed up the adoption of djprobes. could the size restriction of djprobes be relaxed by it doing a deassembly of the instruction? (only to figure out the size of the instruction) basically, i think the best model would be to make djprobes a transparent speedup of kprobes. Ingo