From: Matt Fleming <matt@console-pimps.org>
To: Tejun Heo <tj@kernel.org>, Oleg Nesterov <oleg@redhat.com>
Cc: linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
"H. Peter Anvin" <hpa@zytor.com>,
Matt Fleming <matt.fleming@linux.intel.com>
Subject: [RFC][PATCH 0/5] Improve signal delivery scalability
Date: Tue, 5 Apr 2011 20:21:45 +0100 [thread overview]
Message-ID: <1302031310-1765-1-git-send-email-matt@console-pimps.org> (raw)
From: Matt Fleming <matt.fleming@linux.intel.com>
This series is most definitely RFC material. At this early stage I'm
just asking for feedback on whether the concepts/ideas are sound. For
example, I'm fairly sure that these patches break ia64 because it
accesses tsk->pending in asm and I haven't had time to look closely at
that yet.
This patch series was motivated by the signal1_threads testcase from
the Will It Scale benchmark suite. Currently, signal generation and
delivery in a thread group is serialised by the thread group's
siglock, tsk->sighand->siglock. This lock is a huge point of
contention in multithreaded applications, even when sending a signal
to one thread in a thread group.
In light of this, this patch series tries to improve scalability by,
- introducing a per-thread siglock to protect the per-thread
pending signal queue
- avoiding acquiring the shared siglock wherever possible
- using a rwlock to protect signal handlers
This series is based on the assumption that it is OK to acquire and
release the shared siglock across function calls and do things like
execute PENDING() without holding any locks.
The improvement on the "signal delivery" testcase can be seen here,
http://userweb.kernel.org/~mfleming/will-it-scale/signals-per-thread-siglock/
Tejun, these patches are based on your ptrace branch as both you and
Oleg have touched alot of the same code paths lately.
All comments appreciated!
Matt Fleming (5):
signals: Always place SIGCONT and SIGSTOP on 'shared_pending'
signals: Introduce per-thread siglock and action rwlock
ia64: Catch up with new sighand action spinlock
signals: Introduce __dequeue_private_signal helper function
signals: Don't hold shared siglock across signal delivery
arch/ia64/kernel/signal.c | 13 +--
fs/autofs4/waitq.c | 2 +
fs/exec.c | 2 +
fs/signalfd.c | 7 +-
include/linux/init_task.h | 2 +
include/linux/sched.h | 4 +
include/linux/signal.h | 5 +
include/linux/tracehook.h | 3 +-
kernel/compat.c | 7 +-
kernel/exit.c | 12 +-
kernel/fork.c | 2 +
kernel/kmod.c | 8 +-
kernel/ptrace.c | 4 +-
kernel/signal.c | 429 +++++++++++++++++++++++++++++++++------------
security/selinux/hooks.c | 6 +-
15 files changed, 360 insertions(+), 146 deletions(-)
--
1.7.4
next reply other threads:[~2011-04-05 19:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-05 19:21 Matt Fleming [this message]
2011-04-05 19:21 ` [RFC][PATCH 1/5] signals: Always place SIGCONT and SIGSTOP on 'shared_pending' Matt Fleming
2011-04-05 20:19 ` Oleg Nesterov
2011-04-05 20:50 ` Matt Fleming
2011-04-06 12:57 ` Oleg Nesterov
2011-04-06 13:09 ` Tejun Heo
2011-04-06 13:30 ` Matt Fleming
2011-04-06 13:15 ` Matt Fleming
2011-04-11 18:50 ` Oleg Nesterov
2011-04-11 19:24 ` Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 2/5] signals: Introduce per-thread siglock and action rwlock Matt Fleming
2011-04-13 19:42 ` Oleg Nesterov
2011-04-14 10:34 ` Matt Fleming
2011-04-14 19:00 ` Oleg Nesterov
2011-04-16 13:08 ` Matt Fleming
2011-04-18 16:45 ` Oleg Nesterov
2011-04-21 19:03 ` arch/tile/kernel/hardwall.c:do_hardwall_trap unsafe/wrong usage of ->sighand Oleg Nesterov
2011-04-22 13:04 ` Chris Metcalf
2011-04-26 20:36 ` [PATCH 0/1] tile: do_hardwall_trap: do not play with task->sighand Oleg Nesterov
2011-04-26 20:37 ` [PATCH 1/1] " Oleg Nesterov
2011-05-02 22:42 ` Chris Metcalf
2011-04-26 9:46 ` [RFC][PATCH 2/5] signals: Introduce per-thread siglock and action rwlock Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 3/5] ia64: Catch up with new sighand action spinlock Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 4/5] signals: Introduce __dequeue_private_signal helper function Matt Fleming
2011-04-05 19:21 ` [RFC][PATCH 5/5] signals: Don't hold shared siglock across signal delivery Matt Fleming
2011-04-13 20:12 ` Oleg Nesterov
2011-04-14 10:57 ` Matt Fleming
2011-04-14 19:20 ` Oleg Nesterov
2011-04-16 13:27 ` Matt Fleming
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=1302031310-1765-1-git-send-email-matt@console-pimps.org \
--to=matt@console-pimps.org \
--cc=a.p.zijlstra@chello.nl \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matt.fleming@linux.intel.com \
--cc=oleg@redhat.com \
--cc=tglx@linutronix.de \
--cc=tj@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).