linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yunlong Song <yunlong.song@huawei.com>
To: <a.p.zijlstra@chello.nl>, <paulus@samba.org>, <mingo@redhat.com>,
	<acme@kernel.org>
Cc: <linux-kernel@vger.kernel.org>, <wangnan0@huawei.com>
Subject: [PATCH 2/9] perf sched replay: Increase the MAX_PID value to fix assertion failure problem
Date: Tue, 31 Mar 2015 21:46:29 +0800	[thread overview]
Message-ID: <1427809596-29559-3-git-send-email-yunlong.song@huawei.com> (raw)
In-Reply-To: <1427809596-29559-1-git-send-email-yunlong.song@huawei.com>

Current MAX_PID is only 65536, which will cause assertion failure problem
when CPU cores are more than 64 in x86_64. This is because the pid_max
value in x86_64 is at least PIDS_PER_CPU_DEFAULT * num_possible_cpus()
(see function pidmap_init defined in kernel/pid.c), where
PIDS_PER_CPU_DEFAULT is 1024 (defined in include/linux/threads.h). Thus
for MAX_PID = 65536, the correspoinding CPU cores are 65536/1024=64.
This is obviously not enough at all for x86_64, and will cause an
assertion failure problem due to BUG_ON(pid >= MAX_PID) in the codes.

We increase MAX_PID value from 65536 to 1024*1000, which can be used in
x86_64 with 1000 cores. This number is finally decided according to the
limitation of stack size of calling process. Use 'ulimit -a', the result
shows the stack size of any process is 8192 Kbytes, which is defined in
include/uapi/linux/resource.h (#define _STK_LIM (8*1024*1024)). Thus we
choose a large enough value for MAX_PID, and make it satisfy to the
limitation of the stack size, i.e., making the perf process take up a
memory space just smaller than 8192 Kbytes. We have calculated and
tested that 1024*1000 is OK for MAX_PID. This means perf sched replay
can now be used with at most 1000 cores in x86_64 without any assertion
failure problem.

Example:

Test environment: x86_64 with 160 cores

 $ cat /proc/sys/kernel/pid_max
 163840

Before this patch:

 $ perf sched replay
 run measurement overhead: 240 nsecs
 sleep measurement overhead: 55379 nsecs
 the run test took 1000004 nsecs
 the sleep test took 1059424 nsecs
 perf: builtin-sched.c:330: register_pid: Assertion `!(pid >= 65536)'
 failed.
 Aborted

After this patch:

 $ perf sched replay
 run measurement overhead: 221 nsecs
 sleep measurement overhead: 55397 nsecs
 the run test took 999920 nsecs
 the sleep test took 1053313 nsecs
 nr_run_events:        10
 nr_sleep_events:      1562
 nr_wakeup_events:     5
 task      0 (                  :1:         1), nr_events: 1
 task      1 (                  :2:         2), nr_events: 1
 task      2 (                  :3:         3), nr_events: 1
 task      3 (                  :5:         5), nr_events: 1
 ...

Signed-off-by: Yunlong Song <yunlong.song@huawei.com>
---
 tools/perf/builtin-sched.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c
index a1893e8..c466104 100644
--- a/tools/perf/builtin-sched.c
+++ b/tools/perf/builtin-sched.c
@@ -28,7 +28,7 @@
 #define MAX_CPUS		4096
 #define COMM_LEN		20
 #define SYM_LEN			129
-#define MAX_PID			65536
+#define MAX_PID			1024000
 
 struct sched_atom;
 
-- 
1.8.5.2


  parent reply	other threads:[~2015-03-31 13:44 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-31 13:46 [PATCH 0/9] perf sched replay: Make some improvements and fixes Yunlong Song
2015-03-31 13:46 ` [PATCH 1/9] perf sched replay: Use struct task_desc instead of struct task_task for correct meaning Yunlong Song
2015-04-08 15:11   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` Yunlong Song [this message]
2015-03-31 14:25   ` [PATCH 2/9] perf sched replay: Increase the MAX_PID value to fix assertion failure problem David Ahern
2015-04-01  7:10     ` Yunlong Song
2015-04-08 15:11   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max Yunlong Song
2015-03-31 14:32   ` David Ahern
2015-03-31 15:56     ` Arnaldo Carvalho de Melo
2015-04-01  7:06       ` Yunlong Song
2015-04-07 13:23         ` Yunlong Song
2015-04-07 15:02           ` Arnaldo Carvalho de Melo
2015-03-31 20:25     ` Arnaldo Carvalho de Melo
2015-03-31 22:26       ` David Ahern
2015-03-31 22:35         ` Arnaldo Carvalho de Melo
2015-04-01  7:23     ` Yunlong Song
2015-04-08 15:12   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 4/9] perf sched replay: Realloc the memory of pid_to_task stepwise to adapt to the different pid_max configurations Yunlong Song
2015-04-08 15:12   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 5/9] perf sched replay: Fix the segmentation fault problem caused by pr_err in threads Yunlong Song
2015-04-08 15:12   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 6/9] perf sched replay: Handle the dead halt of sem_wait when create_tasks() fails for any task Yunlong Song
2015-04-08 15:13   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 7/9] perf sched replay: Fix the EMFILE error caused by the limitation of the maximum open files Yunlong Song
2015-04-07 16:49   ` David Ahern
2015-04-08 15:13   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-03-31 13:46 ` [PATCH 8/9] perf sched replay: Support using -f to override perf.data file ownership Yunlong Song
2015-04-08 15:13   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-09-21 13:54   ` [RFC] Perf: Trigger and dump sample info to perf.data from user space ring buffer Yunlong Song
2015-09-21 15:12     ` Borislav Petkov
2015-03-31 13:46 ` [PATCH 9/9] perf sched replay: Use replay_repeat to calculate the runavg of cpu usage instead of the default value 10 Yunlong Song
2015-04-08 15:13   ` [tip:perf/core] " tip-bot for Yunlong Song
2015-04-07  3:20 ` [PATCH 0/9] perf sched replay: Make some improvements and fixes Yunlong Song
2015-04-07 13:53   ` Arnaldo Carvalho de Melo

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=1427809596-29559-3-git-send-email-yunlong.song@huawei.com \
    --to=yunlong.song@huawei.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=wangnan0@huawei.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).