Re: [RFC][PATCH RT] rwsem_rt: Another (more sane) approach to mulit reader rt locks

[Steven Rostedt <rostedt@goodmis.org>]

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.