From: Kirill Tkhai <ktkhai@virtuozzo.com>
To: gregkh@linuxfoundation.org, jslaby@suse.com, oleg@redhat.com,
ebiederm@xmission.com, ktkhai@virtuozzo.com
Cc: linux-kernel@vger.kernel.org
Subject: [PATCH v2 0/3] tty: Make __do_SAK() less greedy in regard to tasklist_lock
Date: Wed, 17 Jan 2018 15:39:24 +0300 [thread overview]
Message-ID: <151619233415.5683.18062849657787533510.stgit@localhost.localdomain> (raw)
Hi,
this patchset makes __do_SAK() to take tasklist_lock for very small time
in comparison to that it does now. Though this function is executed
in process context and it takes tasklist_lock read locked with interrupts enabled,
another tasks may want to take it for writing with interrupt disabled
(e.g., forking tasks), and these tasks may evoke hard lockups.
I've observed several hard lockups caused by long execution of __do_SAK()
on the node with 200 big containers. 3.10 kernel is used there, and mainline
kernel does not have differences in comparation to that, because of __do_SAK()
function has not changed for a long time. So, mainline kernel has this problem too.
The patchset proposes two optimizations in __do__SAK(). The first one is
to skip threads, when they share previous thread's fd table [2/3].
The second optimization is to iterate task list under rcu_read_lock().
This allows to take tasklist_lock for a very small time just to check we
reached the end of the task list. See patch [3/3] for the details.
v2: All three patches changed. Now we don't care about races with
unshare_files() and do not take tasklist_lock on reaching task
list end. Link to v1: https://lkml.org/lkml/2018/1/11/486
Thanks,
Kirill
---
Kirill Tkhai (2):
Revert "do_SAK: Don't recursively take the tasklist_lock"
tty: Use RCU read lock to iterate tasks and threads in __do_SAK()
Oleg Nesterov (1):
tty: Avoid threads files iterations in __do_SAK()
drivers/tty/tty_io.c | 41 ++++++++++++++++++++++++++++-------------
1 file changed, 28 insertions(+), 13 deletions(-)
--
Signed-off-by: Kirill Tkhai <ktkhai@virtuozzo.com>
next reply other threads:[~2018-01-17 12:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-17 12:39 Kirill Tkhai [this message]
2018-01-17 12:39 ` [PATCH v2 1/3] Revert "do_SAK: Don't recursively take the tasklist_lock" Kirill Tkhai
2018-01-17 17:18 ` Eric W. Biederman
2018-01-17 17:34 ` Oleg Nesterov
2018-01-17 17:49 ` Eric W. Biederman
2018-01-17 18:04 ` Oleg Nesterov
2018-01-17 18:37 ` Eric W. Biederman
2018-01-17 20:43 ` Oleg Nesterov
2018-01-18 10:07 ` Kirill Tkhai
2018-01-18 9:59 ` Kirill Tkhai
2018-01-17 12:39 ` [PATCH v2 2/3] tty: Avoid threads files iterations in __do_SAK() Kirill Tkhai
2018-01-17 12:39 ` [PATCH v2 3/3] tty: Use RCU read lock to iterate tasks and threads " Kirill Tkhai
2018-01-17 16:54 ` Eric W. Biederman
2018-01-17 17:39 ` Oleg Nesterov
2018-01-18 10:11 ` Kirill Tkhai
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=151619233415.5683.18062849657787533510.stgit@localhost.localdomain \
--to=ktkhai@virtuozzo.com \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®