From: Feng Tang <feng.tang@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Arjan van de Ven <arjan@linux.intel.com>,
Jonathan Corbet <corbet@lwn.net>, Ingo Molnar <mingo@kernel.org>,
Eric W Biederman <ebiederm@xmission.com>,
Peter Zijlstra <peterz@infradead.org>,
Dmitry Vyukov <dvyukov@google.com>,
Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
Ying Huang <ying.huang@intel.com>,
linux-kernel@vger.kernel.org
Cc: Feng Tang <feng.tang@intel.com>
Subject: [RFC PATCH 2/3] latencytop: split latency_lock to global lock and per task lock
Date: Mon, 29 Apr 2019 16:03:30 +0800 [thread overview]
Message-ID: <1556525011-28022-3-git-send-email-feng.tang@intel.com> (raw)
In-Reply-To: <1556525011-28022-1-git-send-email-feng.tang@intel.com>
Currently there is one global "latency_lock" to cover both the
global and per-task latency data updating. Splitting it into one
global lock and per-task one will improve lock's granularity and
reduce the contention.
Cc: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
include/linux/sched.h | 1 +
init/init_task.c | 3 +++
kernel/fork.c | 4 ++++
kernel/latencytop.c | 9 +++++----
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index f9b43c9..84cf13c 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1095,6 +1095,7 @@ struct task_struct {
unsigned long dirty_paused_when;
#ifdef CONFIG_LATENCYTOP
+ raw_spinlock_t latency_lock;
int latency_record_count;
struct latency_record latency_record[LT_SAVECOUNT];
#endif
diff --git a/init/init_task.c b/init/init_task.c
index 5aebe3b..f7cc0fb 100644
--- a/init/init_task.c
+++ b/init/init_task.c
@@ -158,6 +158,9 @@ struct task_struct init_task
.numa_group = NULL,
.numa_faults = NULL,
#endif
+#ifdef CONFIG_LATENCYTOP
+ .latency_lock = __RAW_SPIN_LOCK_UNLOCKED(init_task.latency_lock),
+#endif
#ifdef CONFIG_KASAN
.kasan_depth = 1,
#endif
diff --git a/kernel/fork.c b/kernel/fork.c
index b69248e..2109468 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1963,6 +1963,10 @@ static __latent_entropy struct task_struct *copy_process(
#ifdef TIF_SYSCALL_EMU
clear_tsk_thread_flag(p, TIF_SYSCALL_EMU);
#endif
+
+#ifdef CONFIG_LATENCYTOP
+ raw_spin_lock_init(&p->latency_lock);
+#endif
clear_all_latency_tracing(p);
/* ok, now we should be set up.. */
diff --git a/kernel/latencytop.c b/kernel/latencytop.c
index 96b4179..6d7a174 100644
--- a/kernel/latencytop.c
+++ b/kernel/latencytop.c
@@ -74,10 +74,10 @@ void clear_all_latency_tracing(struct task_struct *p)
if (!latencytop_enabled)
return;
- raw_spin_lock_irqsave(&latency_lock, flags);
+ raw_spin_lock_irqsave(&p->latency_lock, flags);
memset(&p->latency_record, 0, sizeof(p->latency_record));
p->latency_record_count = 0;
- raw_spin_unlock_irqrestore(&latency_lock, flags);
+ raw_spin_unlock_irqrestore(&p->latency_lock, flags);
}
static void clear_global_latency_tracing(void)
@@ -194,9 +194,10 @@ __account_scheduler_latency(struct task_struct *tsk, int usecs, int inter)
store_stacktrace(tsk, &lat);
raw_spin_lock_irqsave(&latency_lock, flags);
-
account_global_scheduler_latency(tsk, &lat);
+ raw_spin_unlock_irqrestore(&latency_lock, flags);
+ raw_spin_lock_irqsave(&tsk->latency_lock, flags);
for (i = 0; i < tsk->latency_record_count; i++) {
struct latency_record *mylat;
int same = 1;
@@ -234,7 +235,7 @@ __account_scheduler_latency(struct task_struct *tsk, int usecs, int inter)
memcpy(&tsk->latency_record[i], &lat, sizeof(struct latency_record));
out_unlock:
- raw_spin_unlock_irqrestore(&latency_lock, flags);
+ raw_spin_unlock_irqrestore(&tsk->latency_lock, flags);
}
static int lstats_show(struct seq_file *m, void *v)
--
2.7.4
next prev parent reply other threads:[~2019-04-29 8:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 8:03 [RFC PATCH 0/3] latencytop lock usage improvement Feng Tang
2019-04-29 8:03 ` [RFC PATCH 1/3] kernel/sysctl: add description for "latencytop" Feng Tang
2019-04-29 8:03 ` Feng Tang [this message]
2019-04-29 8:03 ` [RFC PATCH 3/3] latencytop: add a lazy mode for updating global latency data Feng Tang
2019-04-30 8:09 ` [RFC PATCH 0/3] latencytop lock usage improvement Peter Zijlstra
2019-04-30 8:35 ` Feng Tang
2019-04-30 9:10 ` Peter Zijlstra
2019-04-30 9:22 ` Feng Tang
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=1556525011-28022-3-git-send-email-feng.tang@intel.com \
--to=feng.tang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@linux.intel.com \
--cc=corbet@lwn.net \
--cc=dvyukov@google.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=ying.huang@intel.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;
as well as URLs for NNTP newsgroup(s).