From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1213 invoked by alias); 24 Nov 2009 20:59:24 -0000 Received: (qmail 1202 invoked by uid 22791); 24 Nov 2009 20:59:23 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 24 Nov 2009 20:59:18 +0000 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAOKxH2q030363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Nov 2009 15:59:17 -0500 Received: from [10.16.2.46] (dhcp-100-2-46.bos.redhat.com [10.16.2.46]) by int-mx03.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nAOKxFAl009337; Tue, 24 Nov 2009 15:59:15 -0500 Message-ID: <4B0C492D.1060602@redhat.com> Date: Tue, 24 Nov 2009 20:59:00 -0000 From: Masami Hiramatsu User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4 MIME-Version: 1.0 To: Frederic Weisbecker 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 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> <20091124201357.GB5071@nowhere> In-Reply-To: <20091124201357.GB5071@nowhere> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: 2009-q4/txt/msg00682.txt.bz2 Frederic Weisbecker wrote: > 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. Yeah, the delayed work is for speeding up batch registration which kprobes are already supported. Sometimes ~100 probes can be set via batch registration I/F. >> 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 It's the next challenge I think :-) Even though, kprobes itself still work on preemptive kernel, so we don't lose any functionality. >> 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(). Ah, right. Even though, we still have an option of ksplice code. Thank you, > PS: hmm btw I remember about a patch that > tagged refrigerator() as __cold but it looks like it hasn't been > applied.... > > Thanks. > -- Masami Hiramatsu Software Engineer Hitachi Computer Products (America), Inc. Software Solutions Division e-mail: mhiramat@redhat.com