From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9841 invoked by alias); 9 Dec 2009 08:44:21 -0000 Received: (qmail 9834 invoked by uid 22791); 9 Dec 2009 08:44:20 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx3.mail.elte.hu (HELO mx3.mail.elte.hu) (157.181.1.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Dec 2009 08:44:15 +0000 Received: from elvis.elte.hu ([157.181.1.14]) by mx3.mail.elte.hu with esmtp (Exim) id 1NII9B-0006U8-4J from ; Wed, 09 Dec 2009 09:43:50 +0100 Received: by elvis.elte.hu (Postfix, from userid 1004) id 046E33E22DC; Wed, 9 Dec 2009 09:43:41 +0100 (CET) Date: Wed, 09 Dec 2009 08:44:00 -0000 From: Ingo Molnar To: Masami Hiramatsu Cc: Frederic Weisbecker , lkml , Steven Rostedt , Jim Keniston , Ananth N Mavinakayanahalli , Christoph Hellwig , "Frank Ch. Eigler" , Jason Baron , "K.Prasad" , Peter Zijlstra , Srikar Dronamraju , Arnaldo Carvalho de Melo , systemtap , DLE Subject: Re: [PATCH -tip 0/8] perf-probe updates Message-ID: <20091209084341.GA21333@elte.hu> References: <20091208220232.10142.2643.stgit@dhcp-100-2-132.bos.redhat.com> <20091209072220.GA4328@elte.hu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091209072220.GA4328@elte.hu> User-Agent: Mutt/1.5.20 (2009-08-17) Received-SPF: neutral (mx3: 157.181.1.14 is neither permitted nor denied by domain of elte.hu) client-ip=157.181.1.14; envelope-from=mingo@elte.hu; helo=elvis.elte.hu; X-ELTE-SpamScore: 0.0 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=0.0 required=5.9 tests=none autolearn=no SpamAssassin version=3.2.5 _SUMMARY_ 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/msg00855.txt.bz2 * Ingo Molnar wrote: > One hickup is that -d/--del does not appear to be working yet: > > # perf probe -l > probe:schedule (on schedule) > > # perf probe -d probe:schedule > Fatal: Failed to write event: Invalid argument Ah, that was with an older kernel - a freshly booted kernel with delete-probe syntax worked fine. There's another small hickup i had - when i typoed 'perf probe -', it gave me: # perf probe - No dwarf info found in the vmlinux - please rebuild with CONFIG_DEBUG_INFO. An error occurred in debuginfo analysis. Try to use symbols. Fatal: Failed to write event: Invalid argument Similar thing happens if i try to probe a non-existent symbol: # perf probe test No dwarf info found in the vmlinux - please rebuild with CONFIG_DEBUG_INFO. An error occurred in debuginfo analysis. Try to use symbols. Fatal: Failed to write event: Invalid argument I think we should print something more helpful, such as: # perf probe test Fatal: Kernel symbol 'test' not found - probe not added. the debuginfo printout is not helpful in this case - we should fall back to symbols silently, unless the nature of the error indicates that we fail _because_ there's no debuginfo. Here the failure was because the symbol does not exist. There's similar problems in most other failure cases. Trying to remove a non-existent probe gives: # perf probe -d test Warning: event "probe:test" is not found. It should say something like: # perf probe -d test Info: event "probe:test" does not exist, could not remove it. Also, it's possible to add multiple probes to the same function, using 'perf probe schedule' + 'perf probe schedule', etc. While in general it makes sense to allow it, by default we should refuse the second, identical probe on the symbol - and add a -f/--force option to force duplicate probes. I.e. the second probe should print: # perf probe schedule Info: event "probe:schedule" already exists. (Use -f to force a duplicate.) etc. Please try out various sensible and also less sensible options of this tool and try to make it break - and see whether the behavior is intuitive and obvious to users - whether the messages are consistent, etc. etc. Ingo