On 06/08/09 3:28 -0700, Paul Menage wrote: > On Thu, Aug 6, 2009 at 2:58 AM, Louis Rilling<Louis.Rilling@xxxxxxxxxxx> wrote: > > > > mutex_lock_nested is not enough, since this would require putting each thread's > > mutex in a different class. Again, something like mutex_lock_nest_lock() is > > the solution, especially since Peter's recent improvement. > > > > OK, well if lockdep can't currently handle the "writer takes a lock on > every thread" model, then maybe we should go with a simpler model > until someone shows a performance issue with it? Ben's original > patches had a per-task_struct lock, and a thread forking with CLONE_VM > would down_read() its group leader's lock. Something that's even > simpler (doesn't have to deal with thread group leader changing due to > an execve()), and avoids the per-task_struct overhead would be to put > the lock in sighand_struct instead (so only one per process). The > procs file writer does a down_write(&tsk->sighand->fork_sem), and > cgroup_fork() can do a down_read(¤t->sighand->fork_sem) if > flags&CLONE_SIGHAND. > > If you put it as the second member of sighand_struct, there wouldn't > even be any extra cacheline bouncing in the common case, since > copy_sighand() would already have brought that line into cache in > order to do atomic_inc(¤t->sighand->count) You meant signal_struct, right? sighand_struct can be shared by several thread groups, while signal_struct can't. Louis -- Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
