On Thu, Aug 6, 2009 at 4:02 AM, Peter Zijlstra<a.p.zijlstra@xxxxxxxxx> wrote:
>
> Taking that many locks in general, some apps (JVM based usually) tend to
> be thread heavy and can easily have hundreds of them, even on relatively
Oh, I'm well aware that apps can be heavily multi-threaded - we have
much worse cases at Google.
>
> Now that's not real nice is it ;-)
Not particularly - but who exactly is going to be moving processes
with thousands of threads between cgroups on a lockdep-enabled debug
kernel?
>
>> But given that AFAICS we can eliminate the overhead associated with a
>> single lock by piggy-backing on the cache line containing
>> sighand->count, hopefully this won't be an issue any more.
>
> Right, so this is a write rarely, read frequently thing, which suggests
> an RCU like approach where the readers pay a minimum synchronization
> penalty.
The documentation for SRCU mentions:
Therefore, SRCU should be used in preference to rw_semaphore
only in extremely read-intensive situations, or in situations
requiring SRCU's read-side deadlock immunity or low read-side
realtime latency.
What benefits does the additional complexity of SRCU give, over the
simple solution of putting an rwsem in the same cache line as
sighand->count ?
Paul
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
