Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753261AbbDAHZD (ORCPT ); Wed, 1 Apr 2015 03:25:03 -0400 Received: from szxga02-in.huawei.com ([119.145.14.65]:27351 "EHLO szxga02-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753219AbbDAHY5 (ORCPT ); Wed, 1 Apr 2015 03:24:57 -0400 Message-ID: <551B9CFD.6090708@huawei.com> Date: Wed, 1 Apr 2015 15:23:41 +0800 From: Yunlong Song User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: David Ahern , , , , CC: , Subject: Re: [PATCH 3/9] perf sched replay: Alloc the memory of pid_to_task dynamically to adapt to the unexpected change of pid_max References: <1427809596-29559-1-git-send-email-yunlong.song@huawei.com> <1427809596-29559-4-git-send-email-yunlong.song@huawei.com> <551AB005.8080102@gmail.com> In-Reply-To: <551AB005.8080102@gmail.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.111.74.205] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2239 Lines: 56 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 >> #include >> #include >> +#include >> >> #define PR_SET_NAME 15 /* Set process name */ >> #define MAX_CPUS 4096 >> @@ -124,7 +125,7 @@ struct perf_sched { >> struct perf_tool tool; >> const char *sort_order; >> unsigned long nr_tasks; >> - struct task_desc *pid_to_task[MAX_PID]; >> + struct task_desc **pid_to_task; >> struct task_desc **tasks; >> const struct trace_sched_handler *tp_handler; >> pthread_mutex_t start_work_mutex; >> @@ -326,8 +327,14 @@ static struct task_desc *register_pid(struct perf_sched *sched, >> unsigned long pid, const char *comm) >> { >> struct task_desc *task; >> + static int pid_max; >> >> - 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; >> + BUG_ON((sched->pid_to_task = calloc(pid_max, sizeof(struct task_desc *))) == NULL); >> + } >> + BUG_ON(pid >= (unsigned long)pid_max); >> > > so why the previous patch bumping the MAX_PID count if you move to dynamic here? And shouldn't MAX_PID get dropped here as well? > > So attached is what i put together last week; just have not had time to send it out. MAX_PID in the previous patch can handle the case when sysctl__read_int("kernel/pid_max", &pid_max) < 0 here in this patch, so I still keep it. However, maybe sysctl__read_int is very unlikely to fail and does not need MAX_PID at all, but keeping MAX_PID here will not introduce any trouble, thus I choose not to drop it. -- Thanks, Yunlong Song -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/