From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6563 invoked by alias); 24 Nov 2009 20:14:10 -0000 Received: (qmail 6555 invoked by uid 22791); 24 Nov 2009 20:14:10 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-ew0-f228.google.com (HELO mail-ew0-f228.google.com) (209.85.219.228) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 20:14:05 +0000 Received: by ewy28 with SMTP id 28so3828293ewy.17 for ; Tue, 24 Nov 2009 12:14:03 -0800 (PST) Received: by 10.213.2.82 with SMTP id 18mr567732ebi.44.1259093643098; Tue, 24 Nov 2009 12:14:03 -0800 (PST) Received: from nowhere (ADijon-552-1-123-3.w92-148.abo.wanadoo.fr [92.148.186.3]) by mx.google.com with ESMTPS id 16sm34557ewy.6.2009.11.24.12.14.00 (version=SSLv3 cipher=RC4-MD5); Tue, 24 Nov 2009 12:14:01 -0800 (PST) Received: by nowhere (nbSMTP-1.00) for uid 1000 (using TLSv1/SSLv3 with cipher RC4-MD5 (128/128 bits)) fweisbec@gmail.com; Tue, 24 Nov 2009 21:14:02 +0100 (CET) Date: Tue, 24 Nov 2009 20:14:00 -0000 From: Frederic Weisbecker To: Masami Hiramatsu Cc: Ingo Molnar , Ananth N Mavinakayanahalli , lkml , systemtap , DLE , Jim Keniston , Srikar Dronamraju , Christoph Hellwig , Steven Rostedt , "H. Peter Anvin" , Anders Kaseorg , Tim Abbott , Andi Kleen , Jason Baron , Mathieu Desnoyers Subject: Re: [PATCH -tip v5 03/10] kprobes: Introduce kprobes jump optimization Message-ID: <20091124201357.GB5071@nowhere> References: <20091123232115.22071.71558.stgit@dhcp-100-2-132.bos.redhat.com> <20091123232141.22071.53317.stgit@dhcp-100-2-132.bos.redhat.com> <20091124024417.GA6752@nowhere> <20091124033135.GE6752@nowhere> <4B0BFCF8.4060905@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0BFCF8.4060905@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 2009-q4/txt/msg00677.txt.bz2 On Tue, Nov 24, 2009 at 10:34:16AM -0500, Masami Hiramatsu wrote: > Frederic Weisbecker wrote: > > I _might_ have understood. > > You have set up the optimized flags, then you wait for > > any old-style int 3 kprobes to complete and route > > to detour buffer so that you can patch the jump > > safely in the dead code? (and finish with first byte > > by patching the int 3 itself) > > > > Yeah, you might get almost correct answer. > The reason why we have to wait scheduling on all processors > is that this code may modify N instructions (not a single > instruction). This means, there is a chance that 2nd to nth > instructions are interrupted on other cpus when we start > code modifying. Aaah ok! In this case, you probably just need the synchronize_sched() thing. The delayed work looks unnecessary. > Please imagine that 2nd instruction is interrupted and > stop_machine() replaces the 2nd instruction with jump > *address* while running interrupt handler. When the interrupt > returns to original address, there is no valid instructions > and it causes unexpected result. Yeah. > > To avoid this situation, we have to wait a scheduler quiescent > state on all cpus, because it also ensure that all current > interruption are done. Ok. > This also excuses why we don't need to wait when unoptimizing > and why it has not supported preemptive kernel yet. I see...so the non-preemptible kernel requirement looks hard to workaround :-s > In unoptimizing case, since there is just a single instruction > (jump), there is no nth instruction which can be interrupted. > Thus we can just use a stop_machine(). :-) Ok. > > On the preemptive kernel, waiting scheduling is not work as we > see on non-preemptive kernel. Since processes can be preempted > in interruption, we can't ensure that the current running > interruption is done. (I assume that a pair of freeze_processes > and thaw_processes may possibly ensure that, or maybe we can > share some stack rewinding code with ksplice.) > So it depends on !PREEMPT. Right. However using freeze_processes() and thaw_processes() would be probably too costly and it's not a guarantee that every processes go to the refrigerator() :-), because some tasks are not freezable, like the kernel threads by default if I remember well, unless they call set_freezable(). That's a pity, we would just have needed to set __kprobe in refrigerator(). PS: hmm btw I remember about a patch that tagged refrigerator() as __cold but it looks like it hasn't been applied.... Thanks.