[lkml]   [2018]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] ftrace: fix task's invalid comm of <...> when big pid
On Thu, 29 Mar 2018 10:16:22 +0800
Wang Yu <> wrote:

> > What you can do is make that map_pid_to_cmdline array bigger.
> >
> > -- Steve
> I am sorry about it, and as the number of cpu cores increases, the current
> PID_MAX_DEFAULT is too small, our online machines set the pid_max 65536 as default, so the task
> pid number bigger than PID_MAX_DEFAULT can't show the real comm (only <...>), so i want to
> ajust the PID_MAX_DEFAULT upto 4x, and what do you think?
> * This controls the default maximum pid allocated to a process
> */
> -#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x8000)
> +#define PID_MAX_DEFAULT (CONFIG_BASE_SMALL ? 0x1000 : 0x20000)

What I was thinking is to make the map_pid_to_cmdline array dynamic
(not static), and be set to pid_max (after pid_max is determined).

Now, pid_max can be changed at run time. Thus, the tracing code will
need to keep a separate variable for that array to store the length. It
can not rely on pid_max. But if a pid that is greater than pid_max is
found, we could kick off a work thread to increase the array.

-- Steve

 \ /
  Last update: 2018-03-29 16:27    [W:0.110 / U:0.732 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site