From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Ingo Molnar <mingo@kernel.org>
Cc: linux-kernel@vger.kernel.org,
Yunlong Song <yunlong.song@huawei.com>,
Paul Mackerras <paulus@samba.org>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Wang Nan <wangnan0@huawei.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: [PATCH 07/16] perf sched replay: Increase the MAX_PID value to fix assertion failure problem
Date: Tue, 7 Apr 2015 13:40:53 -0300 [thread overview]
Message-ID: <1428424862-30032-8-git-send-email-acme@kernel.org> (raw)
In-Reply-To: <1428424862-30032-1-git-send-email-acme@kernel.org>
From: Yunlong Song <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>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1427809596-29559-3-git-send-email-yunlong.song@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.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 a1893e8dfe17..c46610447ede 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.9.3
next prev parent reply other threads:[~2015-04-07 16:44 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-07 16:40 [GIT PULL 00/16] perf/core improvements and fixes Arnaldo Carvalho de Melo
2015-04-07 16:40 ` Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 01/16] perf top: Consider PERF_RECORD_ events with cpumode == 0 Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 02/16] perf evlist: Fix inverted logic in perf_mmap__empty Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 03/16] perf kmaps: Check kmaps to make code more robust Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 04/16] tools lib traceevent: Honor operator priority Arnaldo Carvalho de Melo
2015-04-07 16:40 ` Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 05/16] perf kmem: Respect -i option Arnaldo Carvalho de Melo
2015-04-07 16:40 ` Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 06/16] perf sched replay: Use struct task_desc instead of struct task_task for correct meaning Arnaldo Carvalho de Melo
2015-04-07 16:40 ` Arnaldo Carvalho de Melo [this message]
2015-04-07 16:40 ` [PATCH 08/16] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 09/16] perf sched replay: Realloc the memory of pid_to_task stepwise to adapt to the different pid_max configurations Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 10/16] perf sched replay: Fix the segmentation fault problem caused by pr_err in threads Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 11/16] perf sched replay: Handle the dead halt of sem_wait when create_tasks() fails for any task Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 12/16] perf sched replay: Fix the EMFILE error caused by the limitation of the maximum open files Arnaldo Carvalho de Melo
2015-04-07 16:40 ` [PATCH 13/16] perf sched replay: Support using -f to override perf.data file ownership Arnaldo Carvalho de Melo
2015-04-07 16:41 ` [PATCH 14/16] perf sched replay: Use replay_repeat to calculate the runavg of cpu usage instead of the default value 10 Arnaldo Carvalho de Melo
2015-04-07 16:41 ` [PATCH 15/16] perf record: Add clockid parameter Arnaldo Carvalho de Melo
2015-04-07 19:06 ` David Ahern
2015-04-07 20:20 ` Arnaldo Carvalho de Melo
2015-04-07 16:41 ` [PATCH 16/16] perf tools: Merge all perf_event_attr print functions 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=1428424862-30032-8-git-send-email-acme@kernel.org \
--to=acme@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulus@samba.org \
--cc=wangnan0@huawei.com \
--cc=yunlong.song@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 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.