[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] RT-patch update to remove the global pi_lock

* Steven Rostedt <> wrote:

> Here it is a little ambiguous. The process use to own the lock, but
> someone stole it. When grabbing a lock, I always grab the process
> lock first before grabbing the lock's lock, but this isn't necessary.
> So if you already have the two locks (mutex and process) as is the
> case above, you don't need to unlock them and regrab them (although
> this doesn't hurt, except for performance), because any race would
> have been with the grabbing of these two locks in the first place.
> Now, here's why it's safe. The process that use to own the mutex and
> had it stolen now is out of the chain. The pi_lock and the wait_lock
> here are not in any order. So no one who is grabbing the process'
> pi_lock should have owned the wait_lock and vice versa.
> So here's an updated patch without this lock switching:

your patch works great here, on 3 separate systems: a 1-way, a 2/4-way
and an 8-way.

the 1-way system performed so well running the SMP kernel that i first
thought i booted the UP kernel by accident :-)

on the 8-way box, "hackbench 10" got _3.7_ times faster (!!!).

i have booted the 8-way box without your patch once more because i didnt
believe the results initially and thought they were some benchmarking
fluke. But no, it wasnt a fluke. The kernel profiles are nicely flat

i've released 2.6.13-rc7-rt2 with your patch included. This is certainly
a major milestone for PREEMPT_RT, it is now a first-class scalability
citizen on SMP too. Great work Steven!

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-25 19:49    [W:0.092 / U:3.672 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site