This is in addition to voluntary preempt U5 . So, first apply up to
Voluntary Preempt U4 , then apply this patch. I'll release for U5 as
soon as it's formally released.
We are releasing the following new features,
- Architecture independent mutex with priority inheritance. Note, we
have only tested this in x86.
- Modified latency tracer to trace non-preemptable mutex locking , in
/proc/lock_trace
- Added two new locking functions _mutex_lock_cpu and _mutex_unlock_cpu.
Get the patch at,
ftp://source.mvista.com/pub/realtime/Linux-2.6.9_rc4-mm1-U4.patch
Daniel Walker
* Daniel Walker <[email protected]> wrote:
> This is in addition to voluntary preempt U5 . So, first apply up to
> Voluntary Preempt U4 , then apply this patch. I'll release for U5 as
> soon as it's formally released.
i've released U5 an hour ago.
> We are releasing the following new features,
>
> - Architecture independent mutex with priority inheritance. Note, we
> have only tested this in x86.
there's new generic mutex code in -U5 which covers all the locking
primitives: semaphores, rw-semaphores, spinlock-mutexes and
rwlock-mutexes. PI should be done by improving the existing
rwsem-generic.c code.
> - Modified latency tracer to trace non-preemptable mutex locking , in
> /proc/lock_trace
hm, what is this good for? It is illegal to enter a schedulable section
with preemption disabled and there we currently dump a trace of all
critical sections held - this should be enough to pinpoint the bug.
> - Added two new locking functions _mutex_lock_cpu and
> _mutex_unlock_cpu.
hm, they are unused right now - what will they be used for?
Ingo
On Mon, 2004-10-18 at 10:49 -0700, Daniel Walker wrote:
> - Modified latency tracer to trace non-preemptable mutex locking , in
> /proc/lock_trace
Why?
It is a bug to have preemption disabled when entering non-atomic
(schedulable) code, and a stack trace is dumped if that happens.
Isn't that sufficient?
Robert Love
* Robert Love <[email protected]> wrote:
> On Mon, 2004-10-18 at 10:49 -0700, Daniel Walker wrote:
>
> > - Modified latency tracer to trace non-preemptable mutex locking , in
> > /proc/lock_trace
>
> Why?
>
> It is a bug to have preemption disabled when entering non-atomic
> (schedulable) code, and a stack trace is dumped if that happens.
>
> Isn't that sufficient?
also, i improved that stackdump in the U4/U5 patches (PREEMPT_TRACE) to
include a trace of critical sections held at that moment:
[<c0169dcb>] sys_unlink+0xdc/0x129
[<c01060b5>] sysenter_past_esp+0x52/0x71
preempt count: 00000002
. 2-level deep critical section nesting:
.. entry 1: free_hot_cold_page+0x82/0x149 / (__pagevec_free+0x1f/0x28)
.. entry 2: print_traces+0x1b/0x54 / (dump_stack+0x23/0x25)
While the stackdump indeed is supposed to clearly identify the critical
section, they can be quite large and opaque, sometimes they even lose
the information of where the lock was acquired, and in practice it's
much easier to use PREEMPT_TRACE.
Ingo