Messages in this thread | | | Date | Thu, 6 Aug 2009 04:24:25 -0700 | Subject | Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid at once | From | Paul Menage <> |
| |
On Thu, Aug 6, 2009 at 4:02 AM, Peter Zijlstra<a.p.zijlstra@chello.nl> 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
| |