Andrew Morton wrote:
> On Fri, 17 Nov 2006 10:59:07 +0100
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton writes:
>> > On Thu, 16 Nov 2006 11:55:46 +0100
>> > Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>> >
>> > > Andrew Morton writes:
>> > > > Surely the appropriate beh
On Fri, 17 Nov 2006 11:29:25 +0100, Andi Kleen wrote:
>On Friday 17 November 2006 10:59, Mikael Pettersson wrote:
>
>> It certainly worked when I originally implemented it.
>
>I don't think so. NMI watchdog never recovered no matter if oprofile
>used the counter or not.
If so then that's a bug in
On Friday 17 November 2006 10:59, Mikael Pettersson wrote:
> It certainly worked when I originally implemented it.
I don't think so. NMI watchdog never recovered no matter if oprofile
used the counter or not.
-Andi
-
Take
On Fri, 17 Nov 2006 10:59:07 +0100
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
> > On Thu, 16 Nov 2006 11:55:46 +0100
> > Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> >
> > > Andrew Morton writes:
> > > > Surely the appropriate behaviour is to allow oprofile to st
Andrew Morton writes:
> On Thu, 16 Nov 2006 11:55:46 +0100
> Mikael Pettersson <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton writes:
> > > Surely the appropriate behaviour is to allow oprofile to steal the NMI
> > and
> > > to then put the NMI back to doing the watchdog thing after opro
Hello,
On Thu, Nov 16, 2006 at 10:34:56AM -0500, William Cohen wrote:
>
> Is this going to require sharing the nmi interrupt and knowing which
> perfcounter
> register triggered the interrupt to get the correct action? Currently the
> oprofile interrupt handler assumes any performance monitor
On Thu, 16 Nov 2006 11:55:46 +0100
Mikael Pettersson <[EMAIL PROTECTED]> wrote:
> Andrew Morton writes:
> > Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> > to then put the NMI back to doing the watchdog thing after oprofile has
> > finished with it.
>
> Which is
> What other purposes do you see the performance counters useful for?
Export one to user space as a cycle counter for benchmarking. RDTSC doesn't
do this job anymore.
> To collect information on process characteristics so they can be scheduled
> more efficiently?
That might happen at some po
Andi Kleen wrote:
> On Thursday 16 November 2006 06:05, Andrew Morton wrote:
>
>>On Thu, 16 Nov 2006 04:21:09 +0100
>>Andi Kleen <[EMAIL PROTECTED]> wrote:
>>
>>
If it's really true that oprofile is simply busted then that's a serious
problem and we should find some way of unbusting it. I
Andrew Morton writes:
> Surely the appropriate behaviour is to allow oprofile to steal the NMI and
> to then put the NMI back to doing the watchdog thing after oprofile has
> finished with it.
Which is _exactly_ what pre-2.6.19-rc1 kernels did. I implemented
the in-kernel API allowing real perf
On Thursday 16 November 2006 06:05, Andrew Morton wrote:
> On Thu, 16 Nov 2006 04:21:09 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > >
> > > If it's really true that oprofile is simply busted then that's a serious
> > > problem and we should find some way of unbusting it. If that means ju
On Thu, 16 Nov 2006 04:21:09 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
> >
> > If it's really true that oprofile is simply busted then that's a serious
> > problem and we should find some way of unbusting it. If that means just
> > adding a dummy "0" entry which always returns zero or somethin
On Wed, Nov 15, 2006 at 12:21:18PM -0800, Andrew Morton wrote:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> >
> > > The fact is, it used to work, and the kernel changed interfaces, so now
> > > it
> > > doesn't.
> >
> > No, it didn't work. oprofile may have done something, but it
> > just sil
On Wed, 15 Nov 2006 14:18:24 -0700
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Andrew Morton <[EMAIL PROTECTED]> writes:
>
> > Is it correct to say that oprofile-on-2.6.18 works, and that
> > oprofile-on-2.6.19-rc5 does not?
> >
> > Or is there some sort of workaround for this, or does 2.6.19-
Andrew Morton <[EMAIL PROTECTED]> writes:
> Is it correct to say that oprofile-on-2.6.18 works, and that
> oprofile-on-2.6.19-rc5 does not?
>
> Or is there some sort of workaround for this, or does 2.6.19-rc5 only fail
> in some particular scenarios?
>
> If it's really true that oprofile is simply
On Wed, 15 Nov 2006 20:23:53 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > The fact is, it used to work, and the kernel changed interfaces, so now it
> > doesn't.
>
> No, it didn't work. oprofile may have done something, but it
> just silently killed the NMI watchdog in the process.
> Tha
> The fact is, it used to work, and the kernel changed interfaces, so now it
> doesn't.
No, it didn't work. oprofile may have done something, but it
just silently killed the NMI watchdog in the process.
That was never acceptable.
Now we do proper accounting of NMI sources and also proper allo
On Wed, 15 Nov 2006, Andi Kleen wrote:
> >
> > Meanwhile we should restore the NMI counter to fix this bug.
>
> No, it was always oprofile who was buggy here, silently taking
> the nmi watchdog away.
Andi, your "blame game" doesn't matter.
The fact is, it used to work, and the kernel changed
On Wednesday 15 November 2006 19:39, Andrew Morton wrote:
> On Wed, 15 Nov 2006 17:48:05 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> >
> > > OProfile has a simplistic view of the performance monitoring hardware.
> > > The
> > > routines in libop/op_alloc_counter.c determine what set of pe
On Wed, 15 Nov 2006 17:48:05 +0100
Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > OProfile has a simplistic view of the performance monitoring hardware. The
> > routines in libop/op_alloc_counter.c determine what set of performance
> > registers
> > is available from the processor in use. There i
> OProfile has a simplistic view of the performance monitoring hardware. The
> routines in libop/op_alloc_counter.c determine what set of performance
> registers
> is available from the processor in use. There is no check to see what
> registers
> are actually available in the /dev/oprofile d
21 matches
Mail list logo
