Messages in this thread | | | Date | Sat, 16 Oct 2004 09:56:35 +0200 | From | Ingo Molnar <> | Subject | Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U3 |
| |
* Adam Heath <doogie@debian.org> wrote:
> On Fri, 15 Oct 2004, Ingo Molnar wrote: > > > > > i have released the -U3 PREEMPT_REALTIME patch: > > > > http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.9-rc4-mm1-U3 > > scheduling while atomic: postmaster/0x04000002/3175 > caller is cond_resched+0x53/0x70 > [<c01069f7>] dump_stack+0x17/0x20 > [<c027b457>] schedule+0x517/0x550 > [<c027b9c3>] cond_resched+0x53/0x70 > [<c012cdc7>] _mutex_lock+0x17/0x40 > [<c012ce18>] _mutex_lock_irqsave+0x8/0x10 > [<c01b21ae>] avc_has_perm_noaudit+0x2e/0x180 > [<c01b2335>] avc_has_perm+0x35/0x68 > [<c01b79ca>] ipc_has_perm+0x6a/0x80 > [<c01ab716>] semctl_main+0xa6/0x410 > [<c01abcad>] sys_semctl+0xad/0xb0 > [<c010bafd>] sys_ipc+0xad/0x250 > [<c0105bff>] syscall_call+0x7/0xb
thanks - that's the IPC code that is not converted over from RCU yet.
a suggestion for future testing: please enable PREEMPT_TIMING for the next kernels you build, it will print such entries at the end of stacktraces:
preempt count: 2 entry 1: cpu_idle+0x38/0x90 / (start_kernel+0x1ac/0x1f0) entry 2: _spin_lock+0x22/0x80 / (timer_interrupt+0x1b/0x130)
while in this particular IPC case it's immediately visible that it's the IPC RCU use that is the root of the problem, the preemption trace printout can be very helpful in other cases to quickly identify where the preemptible section was started. E.g. the networking code sometimes has very deep nesting and non-obvious locking. Thanks,
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |