All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vishal Chourasia <vishalc@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, mingo@redhat.com,
	vincent.guittot@linaro.org, vschneid@redhat.com,
	srikar@linux.vnet.ibm.com, sshegde@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org, ritesh.list@gmail.com,
	aneesh.kumar@linux.ibm.com
Subject: Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
Date: Tue, 8 Nov 2022 15:30:46 +0530	[thread overview]
Message-ID: <Y2oozs/YgqqRV5hq@li-05afa54c-330e-11b2-a85c-e3f3aa0db1e9.ibm.com> (raw)
In-Reply-To: <Y1j5cqbyZCDlyaTn@hirez.programming.kicks-ass.net>

[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]


Thanks Greg & Peter for your direction. 

While we pursue the idea of having debugfs based on kernfs, we thought about
having a boot time parameter which would disable creating and updating of the
sched_domain debugfs files and this would also be useful even when the kernfs
solution kicks in, as users who may not care about these debugfs files would
benefit from a faster CPU hotplug operation.

However, these sched_domain debugfs files are created by default.

-- vishal.c

------>8-----------------------------------------------------8<--------------

From f66f66ee05a9f719b58822d13e501d65391dd9d3 Mon Sep 17 00:00:00 2001
From: Vishal Chourasia <vishalc@linux.vnet.ibm.com>
Date: Tue, 8 Nov 2022 14:21:15 +0530
Subject: [PATCH] Add kernel parameter to disable creation of sched_domain
 files

For large systems, creation of sched_domain debug files takes unusually long
time. In which case, sched_sd_export can be passed as kernel command line
parameter during boot time to prevent kernel from creating sched_domain files.

This commit adds a kernel command line parameter, sched_sd_export, which can be
used to, optionally, disable the creation of sched_domain debug files. 
---
 kernel/sched/debug.c    |  9 ++++++---
 kernel/sched/sched.h    |  1 +
 kernel/sched/topology.c | 11 ++++++++++-
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index bb3d63bdf4ae..bd307847b76a 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -279,6 +279,7 @@ static const struct file_operations sched_dynamic_fops = {
 #endif /* CONFIG_PREEMPT_DYNAMIC */
 
 __read_mostly bool sched_debug_verbose;
+__read_mostly int sched_debug_export = 1;
 
 static const struct seq_operations sched_debug_sops;
 
@@ -321,9 +322,11 @@ static __init int sched_init_debug(void)
 	debugfs_create_u32("migration_cost_ns", 0644, debugfs_sched, &sysctl_sched_migration_cost);
 	debugfs_create_u32("nr_migrate", 0644, debugfs_sched, &sysctl_sched_nr_migrate);
 
-	mutex_lock(&sched_domains_mutex);
-	update_sched_domain_debugfs();
-	mutex_unlock(&sched_domains_mutex);
+	if (likely(sched_debug_export)) {
+		mutex_lock(&sched_domains_mutex);
+		update_sched_domain_debugfs();
+		mutex_unlock(&sched_domains_mutex);
+	}
 #endif
 
 #ifdef CONFIG_NUMA_BALANCING
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e26688d387ae..a4d06588d876 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2738,6 +2738,7 @@ extern struct sched_entity *__pick_last_entity(struct cfs_rq *cfs_rq);
 
 #ifdef	CONFIG_SCHED_DEBUG
 extern bool sched_debug_verbose;
+extern int sched_debug_export;
 
 extern void print_cfs_stats(struct seq_file *m, int cpu);
 extern void print_rt_stats(struct seq_file *m, int cpu);
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 8739c2a5a54e..7bcdbc2f856d 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -19,6 +19,13 @@ static int __init sched_debug_setup(char *str)
 }
 early_param("sched_verbose", sched_debug_setup);
 
+static int __init sched_debug_disable_export(char *str)
+{
+	sched_debug_export = 0;
+	return 0;
+}
+early_param("sched_sd_export", sched_debug_disable_export);
+
 static inline bool sched_debug(void)
 {
 	return sched_debug_verbose;
@@ -152,6 +159,7 @@ static void sched_domain_debug(struct sched_domain *sd, int cpu)
 #else /* !CONFIG_SCHED_DEBUG */
 
 # define sched_debug_verbose 0
+# define sched_debug_export 1
 # define sched_domain_debug(sd, cpu) do { } while (0)
 static inline bool sched_debug(void)
 {
@@ -2632,7 +2640,8 @@ void partition_sched_domains_locked(int ndoms_new, cpumask_var_t doms_new[],
 	dattr_cur = dattr_new;
 	ndoms_cur = ndoms_new;
 
-	update_sched_domain_debugfs();
+	if (likely(sched_debug_export))
+		update_sched_domain_debugfs();
 }
 
 /*

base-commit: 7e18e42e4b280c85b76967a9106a13ca61c16179
-- 
2.31.1

  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Vishal Chourasia <vishalc@linux.vnet.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: ritesh.list@gmail.com, vschneid@redhat.com,
	vincent.guittot@linaro.org, srikar@linux.vnet.ibm.com,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-kernel@vger.kernel.org, sshegde@linux.ibm.com,
	mingo@redhat.com, aneesh.kumar@linux.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: sched/debug: CPU hotplug operation suffers in a large cpu systems
Date: Tue, 8 Nov 2022 15:30:46 +0530	[thread overview]
Message-ID: <Y2oozs/YgqqRV5hq@li-05afa54c-330e-11b2-a85c-e3f3aa0db1e9.ibm.com> (raw)
In-Reply-To: <Y1j5cqbyZCDlyaTn@hirez.programming.kicks-ass.net>

[-- Attachment #1: Type: text/plain, Size: 4003 bytes --]


Thanks Greg & Peter for your direction. 

While we pursue the idea of having debugfs based on kernfs, we thought about
having a boot time parameter which would disable creating and updating of the
sched_domain debugfs files and this would also be useful even when the kernfs
solution kicks in, as users who may not care about these debugfs files would
benefit from a faster CPU hotplug operation.

However, these sched_domain debugfs files are created by default.

-- vishal.c

------>8-----------------------------------------------------8<--------------

From f66f66ee05a9f719b58822d13e501d65391dd9d3 Mon Sep 17 00:00:00 2001
From: Vishal Chourasia <vishalc@linux.vnet.ibm.com>
Date: Tue, 8 Nov 2022 14:21:15 +0530
Subject: [PATCH] Add kernel parameter to disable creation of sched_domain
 files

For large systems, creation of sched_domain debug files takes unusually long
time. In which case, sched_sd_export can be passed as kernel command line
parameter during boot time to prevent kernel from creating sched_domain files.

This commit adds a kernel command line parameter, sched_sd_export, which can be
used to, optionally, disable the creation of sched_domain debug files. 
---
 kernel/sched/debug.c    |  9 ++++++---
 kernel/sched/sched.h    |  1 +
 kernel/sched/topology.c | 11 ++++++++++-
 3 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index bb3d63bdf4ae..bd307847b76a 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -279,6 +279,7 @@ static const struct file_operations sched_dynamic_fops = {
 #endif /* CONFIG_PREEMPT_DYNAMIC */
 
 __read_mostly bool sched_debug_verbose;
+__read_mostly int sched_debug_export = 1;
 
 static const struct seq_operations sched_debug_sops;
 
@@ -321,9 +322,11 @@ static __init int sched_init_debug(void)
 	debugfs_create_u32("migration_cost_ns", 0644, debugfs_sched, &sysctl_sched_migration_cost);
 	debugfs_create_u32("nr_migrate", 0644, debugfs_sched, &sysctl_sched_nr_migrate);
 
-	mutex_lock(&sched_domains_mutex);
-	update_sched_domain_debugfs();
-	mutex_unlock(&sched_domains_mutex);
+	if (likely(sched_debug_export)) {
+		mutex_lock(&sched_domains_mutex);
+		update_sched_domain_debugfs();
+		mutex_unlock(&sched_domains_mutex);
+	}
 #endif
 
 #ifdef CONFIG_NUMA_BALANCING
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index e26688d387ae..a4d06588d876 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -2738,6 +2738,7 @@ extern struct sched_entity *__pick_last_entity(struct cfs_rq *cfs_rq);
 
 #ifdef	CONFIG_SCHED_DEBUG
 extern bool sched_debug_verbose;
+extern int sched_debug_export;
 
 extern void print_cfs_stats(struct seq_file *m, int cpu);
 extern void print_rt_stats(struct seq_file *m, int cpu);
diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
index 8739c2a5a54e..7bcdbc2f856d 100644
--- a/kernel/sched/topology.c
+++ b/kernel/sched/topology.c
@@ -19,6 +19,13 @@ static int __init sched_debug_setup(char *str)
 }
 early_param("sched_verbose", sched_debug_setup);
 
+static int __init sched_debug_disable_export(char *str)
+{
+	sched_debug_export = 0;
+	return 0;
+}
+early_param("sched_sd_export", sched_debug_disable_export);
+
 static inline bool sched_debug(void)
 {
 	return sched_debug_verbose;
@@ -152,6 +159,7 @@ static void sched_domain_debug(struct sched_domain *sd, int cpu)
 #else /* !CONFIG_SCHED_DEBUG */
 
 # define sched_debug_verbose 0
+# define sched_debug_export 1
 # define sched_domain_debug(sd, cpu) do { } while (0)
 static inline bool sched_debug(void)
 {
@@ -2632,7 +2640,8 @@ void partition_sched_domains_locked(int ndoms_new, cpumask_var_t doms_new[],
 	dattr_cur = dattr_new;
 	ndoms_cur = ndoms_new;
 
-	update_sched_domain_debugfs();
+	if (likely(sched_debug_export))
+		update_sched_domain_debugfs();
 }
 
 /*

base-commit: 7e18e42e4b280c85b76967a9106a13ca61c16179
-- 
2.31.1

  

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2022-11-08 10:01 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-17 13:10 sched/debug: CPU hotplug operation suffers in a large cpu systems Vishal Chourasia
2022-10-17 14:19 ` Peter Zijlstra
2022-10-17 14:54   ` Greg Kroah-Hartman
2022-10-18 10:37     ` Vishal Chourasia
2022-10-18 11:04       ` Greg Kroah-Hartman
2022-10-18 11:04         ` Greg Kroah-Hartman
2022-10-26  6:37         ` Vishal Chourasia
2022-10-26  6:37           ` Vishal Chourasia
2022-10-26  7:02           ` Greg Kroah-Hartman
2022-10-26  7:02             ` Greg Kroah-Hartman
2022-10-26  9:10             ` Peter Zijlstra
2022-10-26  9:10               ` Peter Zijlstra
2022-11-08 10:00               ` Vishal Chourasia [this message]
2022-11-08 10:00                 ` Vishal Chourasia
2022-11-08 12:24                 ` Greg Kroah-Hartman
2022-11-08 12:24                   ` Greg Kroah-Hartman
2022-11-08 14:51                   ` Srikar Dronamraju
2022-11-08 14:51                     ` Srikar Dronamraju
2022-11-08 15:38                     ` Greg Kroah-Hartman
2022-11-08 15:38                       ` Greg Kroah-Hartman
2022-12-12 19:17                   ` Phil Auld
2022-12-12 19:17                     ` Phil Auld
2022-12-13  2:17                     ` kernel test robot
2022-12-13  2:17                       ` kernel test robot
2022-12-13  6:23                     ` Greg Kroah-Hartman
2022-12-13  6:23                       ` Greg Kroah-Hartman
2022-12-13 13:22                       ` Phil Auld
2022-12-13 13:22                         ` Phil Auld
2022-12-13 14:31                         ` Greg Kroah-Hartman
2022-12-13 14:31                           ` Greg Kroah-Hartman
2022-12-13 14:45                           ` Phil Auld
2022-12-13 14:45                             ` Phil Auld
2023-01-19 15:31                           ` Phil Auld
2023-01-19 15:31                             ` Phil Auld
2022-12-13 23:41                         ` Michael Ellerman
2022-12-13 23:41                           ` Michael Ellerman
2022-12-14  2:26                           ` Phil Auld
2022-12-14  2:26                             ` Phil Auld

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=Y2oozs/YgqqRV5hq@li-05afa54c-330e-11b2-a85c-e3f3aa0db1e9.ibm.com \
    --to=vishalc@linux.vnet.ibm.com \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=ritesh.list@gmail.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=sshegde@linux.ibm.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@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 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.