From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Paul Menage <menage@google.com>, Benjamin Blum <bblum@google.com>,
containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
Ingo Molnar <mingo@elte.hu>, oleg <oleg@redhat.com>
Subject: Re: [PATCH 6/6] Makes procs file writable to move all threads by tgid at once
Date: Thu, 6 Aug 2009 08:19:22 -0700 [thread overview]
Message-ID: <20090806151922.GB6747@linux.vnet.ibm.com> (raw)
In-Reply-To: <1249558761.32113.262.camel@twins>
On Thu, Aug 06, 2009 at 01:39:21PM +0200, Peter Zijlstra wrote:
> On Thu, 2009-08-06 at 04:24 -0700, Paul Menage wrote:
> > 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?
>
> All it takes are: 8 or 48 (or soon 2048) depending on your particular
> annotation. I might and then I'd have to come and kick you ;-)
>
> Really, lockdep not being able to deal with something is a strong
> indication that you're doing something wonky.
>
> Stronger, you can even do wonky things which lockdep thinks are
> absolutely fine.
>
> And doing wonky things should be avoided :-)
>
> Luckily we seem to have found a sensible solution.
>
> > 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 ?
>
> I said:
>
> > Then again, clone() might already serialize on the process as a whole
> > (not sure though, Oleg/Ingo?), in which case you can indeed take a
> > process wide lock.
>
> Which looking up sighand->count seems to be the case:
>
> static int copy_sighand(unsigned long clone_flags, struct task_struct *tsk)
> {
> struct sighand_struct *sig;
>
> if (clone_flags & CLONE_SIGHAND) {
> atomic_inc(¤t->sighand->count);
> return 0;
> }
>
>
> So yes, putting a rwsem in there sounds fine, you're already bouncing
> it.
If the critical section is small, is an rwsem really better than a
straight mutex?
Thanx, Paul
next prev parent reply other threads:[~2009-08-06 15:19 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-31 1:51 [PATCH v2 0/6] CGroups: cgroup memberlist enhancement+fix Ben Blum
2009-07-31 1:51 ` [PATCH 1/6] Adds a read-only "procs" file similar to "tasks" that shows only unique tgids Ben Blum
2009-07-31 1:51 ` [PATCH 2/6] Ensures correct concurrent opening/reading of pidlists across pid namespaces Ben Blum
2009-07-31 1:51 ` [PATCH 3/6] Quick vmalloc vs kmalloc fix to the case where array size is too large Ben Blum
2009-07-31 1:51 ` [PATCH 4/6] Changes css_set freeing mechanism to be under RCU Ben Blum
2009-07-31 1:51 ` [PATCH 5/6] Lets ss->can_attach and ss->attach do whole threadgroups at a time Ben Blum
2009-08-03 2:22 ` Li Zefan
2009-08-04 0:35 ` Benjamin Blum
2009-07-31 1:51 ` [PATCH 6/6] Makes procs file writable to move all threads by tgid at once Ben Blum
2009-08-03 3:00 ` Li Zefan
2009-08-04 0:56 ` Benjamin Blum
2009-08-04 1:05 ` Paul Menage
2009-08-04 1:11 ` Benjamin Blum
2009-08-04 1:09 ` Li Zefan
2009-08-04 1:19 ` Benjamin Blum
2009-08-04 1:45 ` Li Zefan
2009-08-04 1:55 ` Paul Menage
2009-08-03 17:54 ` Serge E. Hallyn
2009-08-03 18:07 ` Paul Menage
2009-08-03 18:13 ` Benjamin Blum
2009-08-03 18:55 ` Serge E. Hallyn
2009-08-03 19:45 ` Serge E. Hallyn
2009-08-03 19:55 ` Paul Menage
2009-08-04 14:01 ` Serge E. Hallyn
2009-08-04 21:40 ` Matt Helsley
2009-08-04 18:48 ` Paul Menage
2009-08-04 19:01 ` Serge E. Hallyn
2009-08-04 19:14 ` Benjamin Blum
2009-08-04 19:28 ` Paul Menage
2009-08-05 10:20 ` Louis Rilling
2009-08-05 16:11 ` Paul Menage
2009-08-05 16:42 ` Louis Rilling
2009-08-05 16:53 ` Peter Zijlstra
2009-08-06 0:01 ` Benjamin Blum
2009-08-06 9:58 ` Louis Rilling
2009-08-06 10:04 ` Louis Rilling
2009-08-06 10:28 ` Paul Menage
2009-08-06 10:34 ` Peter Zijlstra
2009-08-06 10:42 ` Paul Menage
2009-08-06 11:02 ` Peter Zijlstra
2009-08-06 11:24 ` Paul Menage
2009-08-06 11:39 ` Peter Zijlstra
2009-08-06 15:19 ` Paul E. McKenney [this message]
2009-08-06 15:24 ` Peter Zijlstra
2009-08-06 15:37 ` Paul E. McKenney
2009-08-06 11:24 ` Louis Rilling
2009-08-06 11:40 ` Paul Menage
2009-08-06 14:54 ` Louis Rilling
2009-08-08 1:41 ` Benjamin Blum
2009-08-08 1:51 ` Benjamin Blum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090806151922.GB6747@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=bblum@google.com \
--cc=containers@lists.linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mingo@elte.hu \
--cc=oleg@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox