Re: [patch] voluntary-preempt-2.6.9-rc1-bk4-Q7

Mark_H_Johnson
2004-09-02T13:18:45Z

>(you mean 500+ usec, correct?)
>
>there's no way the scheduler can have 500 usecs of overhead going from
>dequeue_task() to __switch_to(): we have all interrupts disabled and
>take zero locks! This is almost certainly some hardware effect (i
>described some possibilities and tests a couple of mails earlier).
>
>In any case, please enable nmi_watchdog=1 so that we can see (in -Q7)
>what happens on the other CPUs during such long delays.

Booted with nmi_watchdog=1, saw the kernel message indicating that
NMI was checked OK.

The first trace looks something like this...

latency 518 us, entries: 79
...
started at schedule+0x51/0x740
ended at schedule+0x337/0x740

00000001 0.000ms (+0.000ms): schedule (io_schedule)
00000001 0.000ms (+0.000ms): sched_clock (schedule)
00010001 0.478ms (+0.478ms): do_nmi (sched_clock)
00010001 0.478ms (+0.000ms): do_nmi (<08049b21>)
00010001 0.482ms (+0.003ms): profile_tick (nmi_watchdog_tick)
...
and a few entries later ends up at do_IRQ (sched_clock).

The second trace goes from dequeue_task to __switch_to with a
similar pattern - the line with do_nmi has +0.282ms duration and
the line notifier_call_chain (profile_hook) as +0.135ms duration.

I don't see how this provides any additional information but will
provide several additional traces when the test gets done in a
few minutes.

--Mark H Johnson
<mailto:Mark_H_Johnson@raytheon.com>