From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5060 invoked by alias); 22 Mar 2006 03:34:20 -0000 Received: (qmail 5052 invoked by uid 22791); 22 Mar 2006 03:34:19 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e2.ny.us.ibm.com (HELO e2.ny.us.ibm.com) (32.97.182.142) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 22 Mar 2006 03:34:18 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e2.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2M3Y638024823 for ; Tue, 21 Mar 2006 22:34:06 -0500 Received: from d01av03.pok.ibm.com (d01av03.pok.ibm.com [9.56.224.217]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2M3Y0J3135398 for ; Tue, 21 Mar 2006 22:34:01 -0500 Received: from d01av03.pok.ibm.com (loopback [127.0.0.1]) by d01av03.pok.ibm.com (8.12.11/8.13.3) with ESMTP id k2M3Y0tN029646 for ; Tue, 21 Mar 2006 22:34:00 -0500 Received: from [127.0.0.1] (sig-9-49-166-239.mts.ibm.com [9.49.166.239]) by d01av03.pok.ibm.com (8.12.11/8.12.11) with ESMTP id k2M3XvQs029484; Tue, 21 Mar 2006 22:34:00 -0500 Message-ID: <4420C5A2.9060702@us.ibm.com> Date: Wed, 22 Mar 2006 03:34:00 -0000 From: Maynard Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Cohen CC: SystemTAP Subject: Re: Proposed systemtap access to perfmon hardware References: <44183FCF.6010809@redhat.com> In-Reply-To: <44183FCF.6010809@redhat.com> 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-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q1/txt/msg00850.txt.bz2 William Cohen wrote: > [snip] > >perfmon_create_context:long () > >The perfmon_create_context command sets up the performance monitoring >hardware for the allocated contexts and starts the counters running. >If successful, the function will return zero. If the operation is >unsuccessful because an error code will be returned. This function >should only be used in probe begin. (FIXME list error code returned.) > > I'm confused about the relationship between this function and perfmon_start_counter, since starting the counters is mentioned in both. Could you explain at what point this function is invoked and what the purpose of the context is? I'm not real familiar with the perfmon2 interface, but just on the face of it, your context doesn't seem like a one-to-one fit with the way contexts are used in perfmon2. In perfmon2, a context is created first, which is then passed in to the calls for setting up events, thereby associating those events with the context. Then 'start' uses the context to set up the PMU for all requested events and begin the counting. > >[snip] > >perfmon_start_counter:long (event_handle:long) > >The event_handle passed in indicates which counter to start. The value >is returned as a 64-bit long of the current counter value. The return >value is undefined for an invalid event_handle. > > I think individually starting counters is problematic at a couple different levels. On some architectures (like PowerPC64), you don't have fine-grained control over each counter. Also, one usually wants all counters to begin counting at the same time. Maybe I'm misinterpreting what the intention of this function is. >[snip] > >EVENT SPECIFICATION > >The performance monitoring events are specified in strings. The >information at the very least include the event name being monitored > > Will, you allude to this in a later posting, but I'll reiterate here. Should the event name be the native event name for the arch? Or some generic name that is mapped to a native name by some mechanism? Or either (as in PAPI)? >by the counter. Additional information would include a event mask to >specify subevents, whether to count in kernel or user space, whether >to keep track of counts on a per thread or per CPU basis, and the >interval for the sampling. > >(FIXME more detail on the string compositions) > > >SYSTEMTAP PERFORMANCE HARDWARE ACCESS IMPLEMENTATION > >The SystemTap access performance monitoring hardware is planned to be >built on the perfmon2 kernel support. The perfom2 provides reservation >and access to the performance monitoring hardware on ia64, i386, and >PowerPC processors. The perfmon2 support is not yet in the upstream >kernels, but patches are available. > > As a proof of concept, I agree that this is the best route. Reinventing the wheel would be useless. Maybe building this prototype might help with refining the perfmon2 interface. > > Regards, -Maynard