On Tue, 2012-05-22 at 19:07 +0200, Thomas Gleixner wrote: > On Tue, 22 May 2012, Steven Rostedt wrote: > > > On Tue, 2012-05-22 at 18:40 +0200, Thomas Gleixner wrote: > > > > > > I'm all for benchmarks. But right now, making all readers pass through a > > > > single mutex is a huge bottle neck for a lot of loads. Yes, they are > > > > mostly Java loads, but for some strange reason, our customers seems to > > > > like to run Java on our RT kernel :-p > > > > > > I'm well aware that mmap_sem is a PITA but replacing one nightmare > > > with the next one is not the best approach. > > > > Perhaps we could just change the mmap_sem to use this approach. Create a > > new type of rwsem/lock for -rt that we can be picky about. > > > > Yeah, mmap_sem is a real PITA and it would be nice to have a solution > > that can be used until we can convert it to an RCU lock. > > That still wants to be verified with numbers on a machine with at > least 32 cores and workloads which are mmap heavy. And before we don't > have such numbers we can really stop arguing about that solution. > Agreed. I now have to find those that complained before, and see how this patch can help. We need the patch to get the numbers (otherwise it's a chicken vs egg deal). I'd also like to see what problems would happen from taking all cpu reader locks for a given writer. I never said that this code must be merged. I want to see the numbers too before we decide anything. I'll still clean up the patch and hopefully we can get others to test it out and give their feedback. Otherwise we're just hand waving back and forth at each other and it's not fair because you have bigger hands that I do ;-) -- Steve PS. Whatever the outcome, I did say that I will *not* be porting this to any of the stable releases, as it is a new 'feature' and not a true bug fix. -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
