lkml.org 
[lkml]   [2008]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [git pull] tracing fixes

* Ingo Molnar <mingo@elte.hu> wrote:

> > > CFLAGS_REMOVE_sched_clock.o = -pg
> > > +CFLAGS_REMOVE_sched.o = -mno-spe -pg
> > > endif
> > >
> >
> > Ingo,
> >
> > Why not trace the scheduler functions? I found a lot of useful
> > information from seeing what functions are being called (namely the
> > latencies caused by the fair scheduler balancing). Not being able to
> > trace sched.c seems to keep a lot of useful data from being accessed.
>
> i agree in general, but it was causing lockups with:
>
> http://redhat.com/~mingo/misc/config-Thu_Jul_17_13_34_52_CEST_2008
>
> note the MAXSMP in the config which sets NR_CPUS to 4096:
>
> CONFIG_NR_CPUS=4096
>
> our randconfig testing stumbled on it. That is a debug helper to "tune
> up the kernel for as large systems as possible" and can bring in
> regressions not normally seen.

ok, figured it out today: the lockups were due to the NMI watchdog and a
missing NMI protection in cpu_clock(). I've reactivated the topic that
solves this problem area and it all works fine now.

the sched.o change probably made a difference just because it reduced
the cross section between the NMI watchdog and the scheduler, making
lockups less likely during the ftrace self-test. I'll revert it once the
tracing/nmisafe is upstream.

Ingo


\
 
 \ /
  Last update: 2008-07-18 12:39    [W:0.085 / U:25.528 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site