I don't have all the context, incl. the patch. But yes, on IA64
Oprofile uses perfmon to program the registers and trigger counter
Using customizable sampling buffer format mechanism, we can connect
the Oprofile sample recording routine to perfmon with only
a few lines of code. The buffer setup and export remains the same.
If I understand your question. You are asking how would Oprofile know
if not all counters are available?
Well, on IA-64, there is no watchdog timer stealing counters. But this
is not a good answer, I'll grant you that.
In perfmon v2.x (x>2), there is a way for an application to query the
registers it has available using pfm_getinfo_evtsets().
This is used on x86 to run in degraded mode, if watchdog is active for
instance. But the mechanism is generic enough
it can apply in other situations.
In the current production IA-64 systems, I think you can look at
/proc/perfmon and it does tell you what is available if I recall.
Note also that if the application tries to write to an unavailable
register, it will get an error, so that is also another way, though
painful, to scan for what's there.
Hope this helps.
On Tue, Jul 15, 2008 at 11:01 PM, Maynard Johnson <maynardj@...> wrote:
> William Cohen wrote:
>> Maynard Johnson wrote:
>>> William Cohen wrote:
>>>> Maynard Johnson wrote:
>>>>> OProfile 0.9.4 Release Candidate 3 is now available and can be found
>>>> On RHEL-5 x86-64, i386, and ia64, built binutils with -fPIC (and
>>>> libtool RPM), then built oprofile without the java support and ran the
>>>> tests. The smoke tests worked okay on the i386 and x86_64. Need to
>>>> take a closer look at what is going on with the smoke tests on ia64
>>>> (RHEL oprofile-0.9.3-16.el5version worked much better); the underlying
>>>> pfmon appears to work on the ia64 machine, but the new oprofile is
>>>> getting the
>>>> following error in ia64 machine:
>>>> Couldn't allocate hardware counters for the selected events.
>>> Curious, especially considering the recently applied patch to
>>> So far, this is the only issue raised against rc3. I had hoped we could
>>> GA 0.9.4 by the end of the week, but I'll hold off until I hear from you
>>> about the underlying cause of this problem.
>>>> The detailed cpu types used for the tests.
>>>> Distro/arch /dev/oprofile/cpu_type
>>>> F-9 x86_64 i386/core_2
>>>> RHEL 5 x86_64 i386/p4-ht
>>>> RHEL 5 i386 timer
>>>> RHEL 5 ia64 ia64/itanium2
>> Hi Maynard,
>> I took a closer look at what is going on. You were right that the
>> op_alloc_counter.c patch was causing a problem. The ia64 is unusual in that
>> it does the actual setup of performance monitoring hardware through perfmon.
>> /dev/oprofile doesn't have any performance register directories, so
>> op_get_counter_mask returns 0. I have attached a proposed patch that
>> assumed that perfmon is managing the counters and looks up the number if
>> there are no counters directories available. This isn't ideal. Assumes
>> perfmon managing and all the registers are available if there are 0
>> I tried out the patched oprofile on ia64, x86_64, and i386. Things work
>> better with the patch.
> So at some point in the past, it was determined that the ia64 oprofile
> kernel driver would not create the counter directories in /dev/oprofile. In
> opcontrol:set_ctr_param(), I see a test for "IS_PERFMON", resulting in an
> immediate exit if true. Given the ia64 kerenel driver's current behavior
> and how opcontrol has been modified to adjust to it, your patch seems as
> good as we can get. But it seems to me this leaves open the very
> possibility your previous patch was trying to prevent -- i.e., that
> something like the watchdog timer holding could have allocated a PMU counter
> and oprofile has no way of knowing about it.
> *Stephane*, can you provide any guidance on this?