All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Matt Fleming <matt@console-pimps.org>
Cc: Oleg Nesterov <oleg@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andi Kleen <andi@firstfloor.org>, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, Tony Luck <tony.luck@intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	David Mosberger-Tang <davidm@egauge.net>
Subject: Re: [RFC][PATCH 0/5] Signal scalability series
Date: Tue, 4 Oct 2011 00:13:35 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.02.1110032345050.1489@ionos> (raw)
In-Reply-To: <1317675520.3375.82.camel@mfleming-mobl1.ger.corp.intel.com>

On Mon, 3 Oct 2011, Matt Fleming wrote:

> On Mon, 2011-10-03 at 18:35 +0200, Oleg Nesterov wrote:
> > On 10/03, Matt Fleming wrote:
> > >
> > > Oh, are you referring to Oleg's email about the slow down under kvm?
> > > Yeah, admittedly that's a pretty clear indicator that something is wrong
> > > with the approach in this patch series.
> > 
> > Or there was something wrong with my testing, please recheck. I specially
> > mentioned I was surprised by the numbers. May be kvm, or lockdep...
> 
> No, I don't think there was anything wrong with your testing method. I
> ran your command-line under Qemu and saw similar results - with the
> patches applied the single-threaded case slows down (not by 50%, it
> looks more like 25%, but that's still unacceptable and not at all what I
> had anticipated).

After staring a bit at your patch I think that you need to tackle that
from a different angle.

The main nuisance of sighand->siglock is the exit race protection and
that's why we need to take it for evrything and some more.

In order to distangle the posix-(cpu)-timer and other stuffs
protection from that single lock, you need to introduce "independent"
locks which basically do the same dance as lock_task_sighand() does
and have to be taken in the exit() path in a well defined order before
manipulating task->sighand.

That way you still cover the exit races, but you can break up the
locking for particular subsystems w/o the need of (much) nesting.

Thanks,

	tglx







  parent reply	other threads:[~2011-10-03 22:13 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-30 15:12 [RFC][PATCH 0/5] Signal scalability series Matt Fleming
2011-09-30 15:12 ` [RFC][PATCH 1/5] signal: Document signal locking rules Matt Fleming
2011-09-30 15:12 ` [RFC][PATCH 2/5] signal: Add rwlock to protect sighand->action Matt Fleming
2011-09-30 15:25   ` Peter Zijlstra
2011-09-30 15:56   ` Matt Fleming
2011-09-30 15:12 ` [RFC][PATCH 3/5] signal: Reduce sighand->siglock hold time in get_signal_to_deliver() Matt Fleming
2011-09-30 15:12 ` [RFC][PATCH 4/5] signal: Add signal->ctrl_lock for job control Matt Fleming
2011-09-30 15:30   ` Peter Zijlstra
2011-09-30 15:36     ` Matt Fleming
2011-09-30 15:12 ` [RFC][PATCH 5/5] signal: Split siglock into shared_siglock and per-thread siglock Matt Fleming
2011-09-30 16:52 ` [RFC][PATCH 0/5] Signal scalability series Oleg Nesterov
2011-09-30 18:54   ` Oleg Nesterov
2011-09-30 20:00   ` Matt Fleming
2011-09-30 23:56     ` Tejun Heo
2011-10-01 10:16       ` Matt Fleming
2011-10-01 13:03         ` Peter Zijlstra
2011-10-03  1:38           ` Tejun Heo
2011-10-03 13:56             ` Thomas Gleixner
2011-10-04  7:37               ` Tejun Heo
2011-10-03 13:07           ` Oleg Nesterov
2011-10-03 15:22             ` Peter Zijlstra
2011-10-04 17:14               ` Oleg Nesterov
2011-10-04 17:52                 ` Oleg Nesterov
2011-10-04 17:54                 ` Linus Torvalds
2011-10-04 18:13                   ` Oleg Nesterov
2011-10-03 13:16     ` Oleg Nesterov
2011-10-04  8:56       ` Matt Fleming
2011-10-04 17:29         ` Oleg Nesterov
2011-09-30 22:30 ` Andi Kleen
2011-10-01  9:35   ` Matt Fleming
2011-10-03 15:28     ` Linus Torvalds
2011-10-03 15:43       ` Matt Fleming
2011-10-03 16:35         ` Oleg Nesterov
2011-10-03 20:58           ` Matt Fleming
2011-10-03 21:45             ` Linus Torvalds
2011-10-03 22:13             ` Thomas Gleixner [this message]
2011-10-04  8:20               ` Matt Fleming
2011-10-04 17:39               ` Oleg Nesterov

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=alpine.LFD.2.02.1110032345050.1489@ionos \
    --to=tglx@linutronix.de \
    --cc=a.p.zijlstra@chello.nl \
    --cc=andi@firstfloor.org \
    --cc=davidm@egauge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matt@console-pimps.org \
    --cc=oleg@redhat.com \
    --cc=tj@kernel.org \
    --cc=tony.luck@intel.com \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.