From: Petr Mladek <pmladek@suse.com>
To: "张元瀚 Tio Zhang" <tiozhang@didiglobal.com>
Cc: Chen Yu <yu.c.chen@intel.com>,
Peter Zijlstra <peterz@infradead.org>,
Vincent Guittot <vincent.guittot@linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Yuanhan Zhang <zyhtheonly@gmail.com>,
"zwp10758@gmail.com" <zwp10758@gmail.com>,
"zyhtheonly@yeah.net" <zyhtheonly@yeah.net>
Subject: Re: [PATCH] sched: print parent comm in sched_show_task()
Date: Wed, 18 Jan 2023 12:06:49 +0100 [thread overview]
Message-ID: <Y8fSyVvnmoNnxiiD@alley> (raw)
In-Reply-To: <37FFCAF0-B0BA-48BD-B688-B1C5E7A10A1A@didiglobal.com>
On Tue 2023-01-17 08:33:56, 张元瀚 Tio Zhang wrote:
> Hi Chen,
> Thanks for your reply! I implement this according to Petr's suggestion here:
>
> > A solution would be to move the parent value to another line.
> > It would even better solve the situation when the task
> > is not alive and we could not get information about the parent:
> >
> > if (pid_alive(p)) {
> > struct parent = rcu_dereference(p->real_parent);
> >
> > pr_info("parent:%-15.15s ppid:%-6d\n",
> > parent->comm, task_pid_nr(parent));
> > }
>
> It seems do break the original format, but I guess printing 0 as ppid when the task is not alive
> would also confuse people sometimes.
Well, a task with pid 0 does not exist so it is not that bad.
But I agree that we could do better.
> For example, when people (and also most system monitor software) see ppid, they read the value in /proc/PID/status. According to task_tgid_nr_ns(), when the task is in a container with its parent outside the
> namespace, we will also see that ppid is 0 inside the container. And in our sched_show_task() here, we are calling task_pid_nr(), so the inconsistency maybe would confuse people under this scenario.
>
> So maybe this new line style would be a better choice? Or we just keep the original format and
> move the parent's info (and should we print the parent's pid again here) to a new line.
What about printing something like:
pr_info("parent:unknown\n");
or
pr_info("parent:unknown ppid:<NULL>;
or
pr_info("parent:???\n");
or
pr_info("parent:unknown (task is exiting)\n");
I slightly prefer the 2nd variant. The <NULL> string makes it rather
clear that the information is not accessible. And pid_alive() actually
does:
return p->thread_pid != NULL;
Best Regards,
Petr
next prev parent reply other threads:[~2023-01-18 11:48 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 10:54 [PATCH] sched: print parent comm in sched_show_task() Tio Zhang
2023-01-16 9:26 ` Chen Yu
2023-01-17 8:33 ` 张元瀚 Tio Zhang
2023-01-18 11:06 ` Petr Mladek [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-12-27 16:14 Tio Zhang
2022-12-29 4:25 ` Chen Yu
[not found] ` <CAEQmJ=gcCx1hMf7HicE5OFeUstipdtr=3JkF1JxLuP-CrG++Pw@mail.gmail.com>
2023-01-04 13:40 ` Petr Mladek
2023-01-06 9:51 ` Chen Yu
[not found] ` <CAEQmJ=gZJL6K1yUPq0hHy5D7Rc6g=5Ri72V_kE=xfqR6gJedWg@mail.gmail.com>
2023-01-12 8:40 ` Chen Yu
2023-01-04 13:24 ` Petr Mladek
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=Y8fSyVvnmoNnxiiD@alley \
--to=pmladek@suse.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tiozhang@didiglobal.com \
--cc=vincent.guittot@linaro.org \
--cc=yu.c.chen@intel.com \
--cc=zwp10758@gmail.com \
--cc=zyhtheonly@gmail.com \
--cc=zyhtheonly@yeah.net \
/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.