Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-04-07 Thread Arnaldo Carvalho de Melo
Em Tue, Apr 07, 2015 at 09:23:46PM +0800, Yunlong Song escreveu: > > The other 6 patches in these patch sets still need to be applied to make > > other improvements > > and bug fixes. > > > > These bugs in 'perf sched replay' reproduce one after another in x86_64 (with > many cores), and > real

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-04-07 Thread Yunlong Song
task->nr, task->comm, task->pid, task->nr_events); >>> } >>> } >>> @@ -2981,6 +2985,12 @@ int cmd_sched(int argc, const char **argv, const >>> char *prefix __maybe_unused) >>> }; >>> unsigned int i; >&

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-04-01 Thread Yunlong Song
On 2015/3/31 22:32, David Ahern wrote: > On 3/31/15 7:46 AM, Yunlong Song wrote: >> diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c >> index c466104..20d887b 100644 >> --- a/tools/perf/builtin-sched.c >> +++ b/tools/perf/builtin-sched.c >> @@ -23,6 +23,7 @@ >> #include >>

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-04-01 Thread Yunlong Song
gt;> + } >> + >> for (i = 0; i < ARRAY_SIZE(sched.curr_pid); i++) >> sched.curr_pid[i] = -1; >> >> -- >> 2.3.0 >> > > > . > I have checked David's patch, the difference with my patch is that David's pat

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread Arnaldo Carvalho de Melo
Em Tue, Mar 31, 2015 at 04:26:04PM -0600, David Ahern escreveu: > On 3/31/15 2:25 PM, Arnaldo Carvalho de Melo wrote: > >Humm, we already have an rb_tree for each task, its called > >machine->threads, and it has struct thread instances, that in turn have > >a ->priv point, can't it be used here? >

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread David Ahern
On 3/31/15 2:25 PM, Arnaldo Carvalho de Melo wrote: Humm, we already have an rb_tree for each task, its called machine->threads, and it has struct thread instances, that in turn have a ->priv point, can't it be used here? I think that would require a lot of churn to the existing code. The co

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread Arnaldo Carvalho de Melo
Em Tue, Mar 31, 2015 at 08:32:37AM -0600, David Ahern escreveu: > On 3/31/15 7:46 AM, Yunlong Song wrote: > >diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c > >index c466104..20d887b 100644 > >--- a/tools/perf/builtin-sched.c > >+++ b/tools/perf/builtin-sched.c > >@@ -23,6 +23,

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread Arnaldo Carvalho de Melo
Em Tue, Mar 31, 2015 at 08:32:37AM -0600, David Ahern escreveu: > On 3/31/15 7:46 AM, Yunlong Song wrote: > >-BUG_ON(pid >= MAX_PID); > >+if (sched->pid_to_task == NULL) { > >+if (sysctl__read_int("kernel/pid_max", &pid_max) < 0) > >+pid_max = MAX_PID; > >+

Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread David Ahern
On 3/31/15 7:46 AM, Yunlong Song wrote: diff --git a/tools/perf/builtin-sched.c b/tools/perf/builtin-sched.c index c466104..20d887b 100644 --- a/tools/perf/builtin-sched.c +++ b/tools/perf/builtin-sched.c @@ -23,6 +23,7 @@ #include #include #include +#include #define PR_SET_NAME

[PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max

2015-03-31 Thread Yunlong Song
The current memory allocation of struct task_desc *pid_to_task[MAX_PID] is in a permanent and preset way, and it has two problems: Problem 1: If the pid_max, which is the max number of pids in the system, is much smaller than MAX_PID (1024*1000), then it causes a waste of stack memory. This may ha