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 behaviour is to allow o
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
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. If that means jus
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
11 matches
Mail list logo
