lkml.org 
[lkml]   [2007]   [Nov]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [perfmon] Re: [perfmon2] perfmon2 merge news
Date
Hi folks,

Well, I can say the mood here at supercomputing'07 is pretty somber
in regards to the latest exchange of messages regarding the perfmon
patches. Our community has been the largest user of both the PerfCtr
and the Perfmon patches, the former being regularly installed by
vendors and integrators on clusters at install time, and the latter
now being adopted into vendor kernels by IBM, Cray, AMD, SiCortex and
others. Of course, adoption by a vendor, does not a good kernel patch
make. However, it should be viewed as a strong data point on demand
for such functionality. We are a community focused on performance and
we have long had a need for these tools.

A solution that does not provide 64 bit virtualized per-thread counts
is not a solution at all. That would need to be ripped out by all of
us using this functionality so we could get something that actually
does what the community needs, not what the you folks think we need.
Device level access and/or root access to the counters is not
unacceptable for machines in production. If that was fine, oprofile
would have satisfied everyone and we wouldn't be sucking up your
bandwidth. Please understand that people outside of the your
community are desperate for adoption of any form of 'per-thread' PMU
functionality into the kernel. For those of you who are (still) not
convinced of this, I can arrange your inbox to be spammed by 1000's
of HPC geeks, managers, vendors, etc. My point is, let's start
somewhere that the community finds useful. Otherwise we run the risk
of developing an interface that everyone isn't comfortable with and
no-one uses. Hardly a productive exercise.

So please, do consider a set of core functionality that provides for
(at least) the following:

- per-CPU and per-thread 64 bit virtualized counts
- third person operation (attach/ptrace)
- dispatch of signal upon interrupt on overflow if requested
- 'buffered' interrupts into a buffer that can be mmap'd into user space
- support for a variety of the major processor platforms

Regards,


On Nov 13, 2007, at 9:55 AM, Stephane Eranian wrote:

> Hello,
>
> On Tue, Nov 13, 2007 at 10:35:11AM -0500, William Cohen wrote:
>> Robert Richter wrote:
>>> On 10.11.07 21:32:39, Andi Kleen wrote:
>>>> It would be really good to extract a core perfmon and start with
>>>> that and then add stuff as it makes sense.
>>>>
>>>> e.g. core perfmon could be something simple like just support
>>>> to context switch state and initialize counters in a basic way
>>>> and perhaps get counter numbers for RDPMC in ring3 on x86[1]
>>>
>>> Perhaps a core could provide also as much functionality so that
>>> Perfmon can be used with an *unpatched* kernel using loadable
>>> modules?
>>> One drawback with today's Perfmon is that it can not be used with a
>>> vanilla kernel. But maybe such a core is by far too complex for a
>>> first merge.
>>>
>>> -Robert
>>>
>>
>> Hi Robert,
>>
>> In the past I suggested that it might be useful to have a version
>> of perfmon2
>> that only set up the perfmon on a global basis. That would allow
>> the patches for
>> context switches to be added as a separate step, splitting up the
>> patch into
>> smaller set of patches.
>>
>> Perfmon2 uses a set of system calls to control the performance
>> monitoring
>> hardware. This would make it difficult to use an unpatch kernel
>> unless perfmon
>> changed the mechanism used to control the performance monitoring
>> hardware.
>>
> Yes, that would be a possibility but as you pointed out there are
> some problems:
>
> - perfmon2 uses system calls. So unless you can dynamically patch the
> syscall table we would have to go back to the ioctl() and driver
> model.
> I was under the impression that people did not quite like
> multiplexing
> syscalls such as ioctl(). I also do prefer the multi syscall
> approach.
>
> - perfmon2 needs to install a PMU interrupt handler. On X86, this
> is not just
> an external device interrupts. There needs to be some APIC and
> interrupt
> gate setup. There maybe other constraints on other architectures
> as well.
> Not sure if all functions/structures necessary for this are
> available to
> modules.
>
> - we could not support per-thread mode with the kernel module
> approach due to
> link to the context switch code. I do believe per-thread is a
> key value-add
> for performance monitoring.
>
> --
> -Stephane
> _______________________________________________
> perfmon mailing list
> perfmon@linux.hpl.hp.com
> http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2007-11-13 20:21    [W:0.153 / U:1.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site