From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6173 invoked by alias); 30 Jan 2007 05:05:56 -0000 Received: (qmail 6161 invoked by uid 22791); 30 Jan 2007 05:05:55 -0000 X-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_40,TW_DJ,UNPARSEABLE_RELAY X-Spam-Check-By: sourceware.org Received: from mail7.hitachi.co.jp (HELO mail7.hitachi.co.jp) (133.145.228.42) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 30 Jan 2007 05:05:47 +0000 Received: from mlsv3.hitachi.co.jp (unknown [133.144.234.166]) by mail7.hitachi.co.jp (Postfix) with ESMTP id 8345E37AD3 for ; Tue, 30 Jan 2007 14:05:45 +0900 (JST) Received: from mfilter-s6.hitachi.co.jp by mlsv3.hitachi.co.jp (8.12.10/8.12.10) id l0U55ka6009376; Tue, 30 Jan 2007 14:05:46 +0900 Received: from vshuts5.hitachi.co.jp (unverified) by mfilter-s6.hitachi.co.jp (Content Technologies SMTPRS 4.3.17) with SMTP id ; Tue, 30 Jan 2007 14:05:45 +0900 Received: from hsdlgw92.sdl.hitachi.co.jp ([133.144.7.20]) by vshuts5.hitachi.co.jp with SMTP id M2007013014054421937 ; Tue, 30 Jan 2007 14:05:44 +0900 Received: from vgate2.sdl.hitachi.co.jp by hsdlgw92.sdl.hitachi.co.jp (8.13.1/3.7W06092911) id l0U55fQR016695; Tue, 30 Jan 2007 14:05:44 +0900 Received: from maila.sdl.hitachi.co.jp ([133.144.14.196]) by vgate2.sdl.hitachi.co.jp (SAVSMTP 3.1.1.32) with SMTP id M2007013014054424644 ; Tue, 30 Jan 2007 14:05:44 +0900 Received: from [127.0.0.1] ([10.232.9.172]) by maila.sdl.hitachi.co.jp (8.13.1/3.7W04031011) with ESMTP id l0U55fEG005166; Tue, 30 Jan 2007 14:05:44 +0900 Message-ID: <45BED225.9010600@hitachi.com> Date: Tue, 30 Jan 2007 05:05:00 -0000 From: Masami Hiramatsu Organization: Systems Development Lab., Hitachi, Ltd., Japan User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Quentin Barnes Cc: Satoshi Oshima , Hideo Aoki , Yumiko Sugita , SystemTAP Subject: Re: boosting with preemptable kernel References: <20061117235807.GB11523@urbana.css.mot.com> <45624C0D.3030007@hitachi.com> <20070103223912.GA13162@urbana.css.mot.com> <45A99FC3.5050805@hitachi.com> <20070127063742.GA18383@urbana.css.mot.com> In-Reply-To: <20070127063742.GA18383@urbana.css.mot.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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: 2007-q1/txt/msg00265.txt.bz2 Hi Quentin, Quentin Barnes wrote: >> Djprobe has to rewrite multiple instructions on i386 (CISC), because >> the size of the long jump instruction is bigger than many instructions. >> Before rewriting those instructions, we must ensure no other processes >> running/sleeping on the target instructions which will be rewritten by >> the long jump. This case can not be helped by the trampoline routine. > > Yes, that's a very, very messy problem on the x86. Up to five(?) > instructions could be overwritten by the long jump instruction. > > I'm still not sure though I see why a trampoline approach wouldn't > work for x86. It would just have to iterate the trampoline up to > five times. But I still don't have the model clear enough in my > head yet. Maybe it will become clearer over time. Similar idea had discussed with Karim on the thread below: http://sourceware.org/ml/systemtap/2006-q3/msg00725.html > As long as the kernel text address space stays under 32MB, an > ARM djprobe implementation would be a one-for-one instruction > replacement. Unfortunately, the djprobe allocates its stub buffer from the module area. Is it included in the 32MB area on ARM? > I'm still absorbing the djprobes explanation (djprobe-20051031.txt) > and perusing the patch you sent out Nov 21. Sorry if the following > question has already been discussed. If it has, just point me to > it. Is there a reason djprobes needs its own, separate interface? > Could it just use the kprobes registration service and have the > kprobes code decide whether to implement a given probe as a kprobe > with an exception or djprobe with a direct jump? Or is this a long > term goal after shaking out the djprobes model? Before I sent the latest patch, we are discussed that. The patch which I sent Nov 21, integrated the djprobe's interface into kprobe's interface. If user sets the length of the instructions (which will be replaced by a long jump) to the length member of the kprobe data structure, that kprobe will be optimized (become a djprobe) after invoking commit_kprobes(). Best regards, -- Masami HIRAMATSU Linux Technology Center Hitachi, Ltd., Systems Development Laboratory E-mail: masami.hiramatsu.pt@hitachi.com