From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756805AbZINSzp (ORCPT ); Mon, 14 Sep 2009 14:55:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756793AbZINSzo (ORCPT ); Mon, 14 Sep 2009 14:55:44 -0400 Received: from ey-out-2122.google.com ([74.125.78.27]:49882 "EHLO ey-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755044AbZINSzn (ORCPT ); Mon, 14 Sep 2009 14:55:43 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=MRIAmmmcGkC7MGQMyYvG3F2KkcCno8Iomai8NJrDQQwcB/aC8mcb0rjyZSFN2ChGhs HTtxI+daqf8x+yXCKN8HwDz7ZktT6H5m+zNkrUYlxBPz8Stk++1KaahTlhPegQbCBlIu EnUnQ9JDep2Lw4Izdr8MHSZ7VIdPee2w8PbPM= Date: Mon, 14 Sep 2009 20:55:41 +0200 From: Frederic Weisbecker To: Masami Hiramatsu Cc: Steven Rostedt , Ingo Molnar , lkml , systemtap , DLE , Jim Keniston , Ananth N Mavinakayanahalli , Andi Kleen , Christoph Hellwig , "Frank Ch. Eigler" , "H. Peter Anvin" , Jason Baron , "K.Prasad" , Lai Jiangshan , Li Zefan , Peter Zijlstra , Srikar Dronamraju , Tom Zanussi Subject: Re: [PATCH tracing/kprobes 4/7] tracing/kprobes: Add event profiling support Message-ID: <20090914185540.GD6045@nowhere> References: <20090910235258.22412.29317.stgit@dhcp-100-2-132.bos.redhat.com> <20090910235329.22412.94731.stgit@dhcp-100-2-132.bos.redhat.com> <20090911031253.GD16396@nowhere> <4AAA7938.7070200@redhat.com> <20090914030244.GC14306@nowhere> <4AAE7540.9090009@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AAE7540.9090009@redhat.com> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 14, 2009 at 12:54:24PM -0400, Masami Hiramatsu wrote: >>> I'd like to have a dispatcher function and flags internally :) >> >> >> You mean kprobes that could support multiple probes? >> That would be a nice solution IMHO... > > Yeah, actually kprobes could support multiple probes on the > same point. But kprobe structure has many extensions which > kprobe-tracer doesn't need, e.g. post_handler/break_handler, > opcode, arch sprcific instructions. > Kretprobe consumes more memories for storing return points :(. > > Thus, if we know there are two functions to be called on the > same probe point, I think it is better to have a dispatcher. > (Especially, in this case, we can call fixed functions, so > it's easier way.) > Yeah, you could union the post_handler with profile_handler or something like that. It depends if kprobes may need one day to support an undeterminate number of probes. Also, is the post_handler called at the same location than the normal probe? And is a post handler called even if there is no normal handler? There might be some of such factors that would force you to handle a lot of corner cases, things that you wouldn't need to worry about if you just had to maintain a simple rcu list of probes to call.