linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 06/19] perf sched replay: Increase the MAX_PID value to fix assertion failure problem
Date: Wed,  8 Apr 2015 11:23:26 -0300	[thread overview]
Message-ID: <1428503019-23820-7-git-send-email-acme@kernel.org> (raw)
In-Reply-To: <1428503019-23820-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


  parent reply	other threads:[~2015-04-08 14:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-08 14:23 [GIT PULL 00/19] perf/core improvements and fixes Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 01/19] perf evlist: Fix inverted logic in perf_mmap__empty Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 02/19] perf kmaps: Check kmaps to make code more robust Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 03/19] tools lib traceevent: Honor operator priority Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 04/19] perf kmem: Respect -i option Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 05/19] perf sched replay: Use struct task_desc instead of struct task_task for correct meaning Arnaldo Carvalho de Melo
2015-04-08 14:23 ` Arnaldo Carvalho de Melo [this message]
2015-04-08 14:23 ` [PATCH 07/19] 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-08 14:23 ` [PATCH 08/19] 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-08 14:23 ` [PATCH 09/19] perf sched replay: Fix the segmentation fault problem caused by pr_err in threads Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 10/19] perf sched replay: Handle the dead halt of sem_wait when create_tasks() fails for any task Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 11/19] perf sched replay: Fix the EMFILE error caused by the limitation of the maximum open files Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 12/19] perf sched replay: Support using -f to override perf.data file ownership Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 13/19] 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-08 14:23 ` [PATCH 14/19] perf record: Add clockid parameter Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 15/19] perf tools: Merge all perf_event_attr print functions Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 16/19] perf probe: Fix ARM 32 building error Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 17/19] perf tests: Fix attr tests Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 18/19] perf report: Don't call map__kmap if map is NULL Arnaldo Carvalho de Melo
2015-04-08 14:23 ` [PATCH 19/19] perf tools: Add 'I' event modifier for exclude_idle bit Arnaldo Carvalho de Melo
2015-04-08 15:05 ` [GIT PULL 00/19] perf/core improvements and fixes Ingo Molnar

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=1428503019-23820-7-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 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).