Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid at once

[Paul Menage <menage@google.com>]

On Thu, Aug 6, 2009 at 3:34 AM, Peter Zijlstra<a.p.zijlstra@chello.nl> wrote:
> On Thu, 2009-08-06 at 03:28 -0700, Paul Menage wrote:
>
>> OK, well if lockdep can't currently handle the "writer takes a lock on
>> every thread" model,
>
> I haven't read what this is about, but simply looking at that sentence
> makes me want to hit someone with a cluebat. Have you any idea how
> expensive that is?

For lockdep to track that many locks, or just the concept of taking
that many locks generally?

The basic idea is that in order to implement a "procs" file in cgroups
that can migrate all threads in a process atomically, we need to
synchronize with concurrent clone() calls. But since thread clones are
likely to occur far more often than "procs" writes, and we wanted to
avoid introducing overhead into the clone path, one approach was to
give each thread a fork mutex, which it could take around the relevant
parts of the fork/clone operation, and have the "procs" writer deal
with obtaining the fork mutex for every thread in the process being
moved, so pushing the overhead on to the "procs" writer.

I don't think it's a deficiency of lockdep that it would have trouble
dealing with this - in fact, my original plan was that we'd just have
to live with the fact that anyone doing a "procs" move on a massive
process would have to live with lockdep printing an overflow warning.
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.

Paul