Messages in this thread | | | Date | Thu, 25 Aug 2005 19:47:32 +0200 | From | Ingo Molnar <> | Subject | Re: [RFC] RT-patch update to remove the global pi_lock |
| |
* Steven Rostedt <rostedt@goodmis.org> 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 now.
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!
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/
| |