Philip J. Mucci wrote:
> Basically, reading the counters is a 2 step process: read the mmapped
> virtual counters and add that to the contents of rdpmc(). This means
> that (at least for the x86 series) the kernel interface only needs to
> 'guard' access to the MSR to make sure the user doesn't se
Hi David, Ingo, Keith, Kier and all,
As the developer of PAPI, I can only reiterate what Ingo and David have
suggested. The user base of people wanting access to performance
counters has
greatly expanded. PAPI has now been out for over a year and a half and
we get pings from developers across the
On Sun, 1 Oct 2000 23:30:14 +0200 (MET DST),
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>The upapic-2.4.0-test9-C3 patch has another problem.
>
>On Fri, 29 Sep 2000, Udo A. Steinberg wrote:
>
>>I've been giving the patch a try, however it hangs my machine during boot.
>>Here's the important bit
On Sat, 30 Sep 2000, Ingo Molnar wrote:
>
> On Sat, 30 Sep 2000, Keith Owens wrote:
>
> > via /dev/msr. On SMP you end up with two sources of NMI, local APIC
> > on every cpu plus IO-APIC. The code in linux/arch/i386/kernel/traps.c
> > resets PERFCTR1 on every NMI, [...]
>
> yep, than
On Sat, 30 Sep 2000, Keith Owens wrote:
> via /dev/msr. On SMP you end up with two sources of NMI, local APIC
> on every cpu plus IO-APIC. The code in linux/arch/i386/kernel/traps.c
> resets PERFCTR1 on every NMI, [...]
yep, thanks, thats a bug, i'll fix it.
Ingo
-
To unsubscribe fro
On Fri, 29 Sep 2000 10:00:37 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>On Fri, 29 Sep 2000, Keith Owens wrote:
>
>> arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A
>
>there is nothing performance-counter specific about /dev/msr. There is no
>highlevel performance-
Ingo Molnar <[EMAIL PROTECTED]> writes:
> that having all said, i'm not against a generic, nonpriviledged (kernel
> based) performance counter API within the kernel (if there is demand), and
> such an API should of course have close control over the contents of the
> performance counter registers
On Fri, 29 Sep 2000, Ingo Molnar wrote:
> yep, this was my point. Eg. i dont think we cleared the performance
> counters on AP APICs before, so in theory, if some other OS sets them up
> and Linux is soft-booted (or loadlin-ed), then there might be boot
> problems.
Hmm, on a second thought, I r
On Fri, 29 Sep 2000, John Levon wrote:
> prumpf has been talking about using some counter information for
> scheduling/VM purposes as well ...
yep, i planned something like this about 2 years ago - in fact the
current->avg_slice scheduler feature some time ago (which used the cycle
counter to m
On Fri, 29 Sep 2000, Ingo Molnar wrote:
> that having all said, i'm not against a generic, nonpriviledged (kernel
> based) performance counter API within the kernel (if there is demand), and
> such an API should of course have close control over the contents of the
> performance counter registers
On Fri, 29 Sep 2000, Ingo Molnar wrote:
> i'm wondering wether this missing clear_APIC() could explain some of the
> more mysterious boot problems we had?
I don't think so. Unless we have an i82489DX APIC in th PIC mode, the
BSP APIC must be set up into the Virtual Wire mode or DOS, etc. won't
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote:
> [...] AP APICs might be setup randomly, though. [...]
yep, this was my point. Eg. i dont think we cleared the performance
counters on AP APICs before, so in theory, if some other OS sets them up
and Linux is soft-booted (or loadlin-ed), then there
On Fri, 29 Sep 2000, Keir Fraser wrote:
> Thanks for the info: I'd entirely forgotten about the inter-APIC comms
> bus. That given, I have no problem with clearing the perfctr before
> use. The NMI oopser has saved my bacon on more than one occasion :)
i'm glad to hear that :-) If you have an S
> what is wrong with clearing the first performance counter before using it?
> The NMI oopser is completely nonintrusive.
>
> so on UP systems you'll have to choose between the NMI oopser and other
> uses of the first counter. You can save/restore the contents of the first
> counter if you want t
On Fri, 29 Sep 2000, Keir Fraser wrote:
> Another question relating to the setup of local APICs on current
> -testX kernels: how are external interrupts routed through to the
> processor? I thought that setup_local_APIC() used LVT0 to pick up
> external interrupts, but setup_nmi_watchdog() reconf
On Fri, 29 Sep 2000, Keir Fraser wrote:
> > Is it really necessary to use one of the event counters ? this means
> > those of us using event counters from modules can't use this oopser at
> > the same time, which is a pity.
> Indeed. What was wrong with the existing method, where you route an
>
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote:
> > i've left the i82489DX path unchanged - except for the (generic) fix to
> > consistencly clear the local APIC in on all CPUs, not just the BSP. I
> > cannot see how this can impact the i82489DX path.
>
> I've missed that bit, sorry. I'll look a
On Fri, 29 Sep 2000, Ingo Molnar wrote:
> i've left the i82489DX path unchanged - except for the (generic) fix to
> consistencly clear the local APIC in on all CPUs, not just the BSP. I
> cannot see how this can impact the i82489DX path.
I've missed that bit, sorry. I'll look at the patch more
> > ... and adds the enabling code of Keith Owens which
> > programs P6 performance counter 0 as an NMI. (i simplified the code alot -
> > there is no problem at all with getting NMIs from two sources, and it's
> > not necessary to make it configurable.)
>
> Is it really necessary to use one of t
On Fri, 29 Sep 2000, John Levon wrote:
> Is it really necessary to use one of the event counters ? this means
> those of us using event counters from modules can't use this oopser at
> the same time, which is a pity.
well, you can still use the other event counter. And you can clear the
first c
On Fri, 29 Sep 2000, John Levon wrote:
> Is it really necessary to use one of the event counters ? this means those
> of us using event counters from modules can't use this oopser at
> the same time, which is a pity.
>
>
> Can you not set up the actual APIC timer on a local APIC to deliver NMI
On Thu, 28 Sep 2000, Ingo Molnar wrote:
>
> the attached patch (against test9-pre7) is a cleaned up version Keir
> Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
> programs P6 performance counter 0 as an NMI. (i simplified the code alot -
> there is no problem at all
On Fri, 29 Sep 2000, Maciej W. Rozycki wrote:
> which your patch addresses. Please leave the i82489DX path unchanged
> -- it's too fragile.
i've left the i82489DX path unchanged - except for the (generic) fix to
consistencly clear the local APIC in on all CPUs, not just the BSP. I
cannot see h
On Thu, 28 Sep 2000, Ingo Molnar wrote:
> the attached patch (against test9-pre7) is a cleaned up version Keir
> Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
> programs P6 performance counter 0 as an NMI. (i simplified the code alot -
> there is no problem at all wit
On Fri, 29 Sep 2000, Keith Owens wrote:
> arch/i386/kernel/msr.c has been there since at least 2.4.0-test1. A
there is nothing performance-counter specific about /dev/msr. There is no
highlevel performance-counter logic in the kernel. So if the kernel
decides to use one of them, that should no
On Fri, 29 Sep 2000 03:03:30 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
>On Fri, 29 Sep 2000, Keith Owens wrote:
>
>> [...] You prefer to make NMI for UP mandatory, change the existing
>> behaviour and force people who use performance counters to turn off
>> EVNTSEL1 themselves. [...]
On Fri, 29 Sep 2000, Keith Owens wrote:
> [...] You prefer to make NMI for UP mandatory, change the existing
> behaviour and force people who use performance counters to turn off
> EVNTSEL1 themselves. [...]
no, AFAIK there is no performance counter support in the vanilla kernel,
but there is a
On Fri, 29 Sep 2000 01:13:06 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>On Fri, 29 Sep 2000, Keith Owens wrote:
>> Using performance counter 1 for NMI conflicts with using the
>> performance counters for tuning. IMHO it is better to default to NMI
>> off for UP so we do not disturb peo
On Fri, 29 Sep 2000, Keith Owens wrote:
> Using performance counter 1 for NMI conflicts with using the
> performance counters for tuning. IMHO it is better to default to NMI
> off for UP so we do not disturb people who are doing performance
> monitoring. [...]
the number of people experiencing
On Thu, 28 Sep 2000 21:19:29 +0200 (CEST),
Ingo Molnar <[EMAIL PROTECTED]> wrote:
>the attached patch (against test9-pre7) is a cleaned up version Keir
>Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
>programs P6 performance counter 0 as an NMI. (i simplified the code
On Fri, 29 Sep 2000, Udo A. Steinberg wrote:
> Machine is an uniprocessor AMD Thunderbird on an Asus A7V mobo.
hm, it will not work on class 6 AMD systems. I'll fix this.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
Ingo Molnar wrote:
>
> the attached patch (against test9-pre7) is a cleaned up version Keir
> Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
> programs P6 performance counter 0 as an NMI. (i simplified the code alot -
> there is no problem at all with getting NMIs from
On Fri, 29 Sep 2000, Miles Lane wrote:
> Cool. Is there anything else I need to know in order to the
> UP-NMI-oopser effectively? It sounds like it'll just force an OOPS to
> occur where a deadlock might have occured in the past. Is this
> correct? If so, then using it is easy and I'll just see
Ingo Molnar wrote:
> if SysRq works then this is a 'soft lockup', and if you want to debug this
> then you should capture the EIP values from RightAlt+ScrLk output, thats
> the place where it locks up. The UP-NMI-oopser will not help.
>
> Ingo
Cool. Is there anything else I need to kn
Ingo,
Can you please outline exactly what testers with UP machines
need to do to build, set up, enable and debug using this
new code?
I have an Athlon 750MHz machine and a Pentium II laptop
that I use for testing and I'd like to exercise some of
the experimental VM code. I have gotten system
On Fri, 29 Sep 2000, Miles Lane wrote:
> how best to extract useful debugging information from the deadlocked
> systems. Any help you can give in this regard would be much
> appreciated. I have used SysRq successfully, but I don't know how to
> use the information I am given to find the salient
the attached patch (against test9-pre7) is a cleaned up version Keir
Fraser's APIC-on-UP patch, and adds the enabling code of Keith Owens which
programs P6 performance counter 0 as an NMI. (i simplified the code alot -
there is no problem at all with getting NMIs from two sources, and it's
not ne
37 matches
Mail list logo
