From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26566 invoked by alias); 23 Mar 2006 12:54:57 -0000 Received: (qmail 26546 invoked by uid 22791); 23 Mar 2006 12:54:56 -0000 X-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from e33.co.us.ibm.com (HELO e33.co.us.ibm.com) (32.97.110.151) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 23 Mar 2006 12:54:54 +0000 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.12.11/8.12.11) with ESMTP id k2NCsqOd027981 for ; Thu, 23 Mar 2006 07:54:52 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k2NCpoOa226022 for ; Thu, 23 Mar 2006 05:51:50 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k2NCsqfn002591 for ; Thu, 23 Mar 2006 05:54:52 -0700 Received: from [127.0.0.1] (sig-9-76-71-239.mts.ibm.com [9.76.71.239]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k2NCsocr002504; Thu, 23 Mar 2006 05:54:51 -0700 Message-ID: <44229A9D.3050409@us.ibm.com> Date: Thu, 23 Mar 2006 12:54: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: "Stone, Joshua I" CC: William Cohen , SystemTAP Subject: Re: Proposed systemtap access to perfmon hardware References: In-Reply-To: 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/msg00862.txt.bz2 Stone, Joshua I wrote: >Maynard Johnson wrote: > > >>William Cohen wrote: >> >> >>>The individual start and stop operations would be allowed. >>> >>> >>This is not so good. Besides the fact that it may be difficult (or >>impossible) to do, I don't see it being all that useful. But then, >>I'm a tool developer, not a performance analyst, so I could be >>missing the point. >> >> > >Enabling start & stop lets you narrow the context that you want to >measure. Perfmon can only give you thread level virtualization of the >counters. With start & stop I can, for example, start the counters when >I enter sys_open and stop when I return. Now if I want I can get a >microbenchmark of IPC for the sys_open call (and its callees). > >But this also opens up possibilities for more obscure "contexts" - >perhaps I want to start counting when a network packet is received and >stop when it is delivered to the thread. Any probepoint you can do >today can become a start/stop point for the counters. > > Yes, I can certainly see this benefit. It gives you PAPI-level control without having to modify source code. My concern, however, was that if you have multiple counters configured, then individual control of them presents an extra level of difficulty. But, as I've been thinking about this a bit more, I think this could be done if you can guarantee that the operation is not preempted or interrupted. Then, the PMU can be disabled, reloaded with any changes, and then re-enabled. Then, any counters that had been running before the operation -- and that were not changed by the operation -- will be reloaded with their previous count and continue running from where they left off. -Maynard > >Josh > >