[patch] Voluntary Preempt additions

[patch] Voluntary Preempt additions

[Daniel Walker]

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

Re: [patch] Voluntary Preempt additions

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> 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

Re: [patch] Voluntary Preempt additions

[Robert Love]

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

Re: [patch] Voluntary Preempt additions

[Ingo Molnar]

* Robert Love <rml@novell.com> 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