Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp6357965rwb; Wed, 18 Jan 2023 04:17:46 -0800 (PST) X-Google-Smtp-Source: AMrXdXt/w4AbWKBstOrxZ3c/aLM+85W8pc+7TcTE3Vh1dNxejaBXNcT+hrDYx+b+zfC1HUnpRTo1 X-Received: by 2002:a17:906:3a4d:b0:873:393f:1bda with SMTP id a13-20020a1709063a4d00b00873393f1bdamr4767611ejf.47.1674044266257; Wed, 18 Jan 2023 04:17:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674044266; cv=none; d=google.com; s=arc-20160816; b=FdV2Gw6j4Y43XIr9mU53y8wkkJOb5/skWm5KePf5yOGzYI9ehuvo6KZTTYVkVXFVS2 ITz3Ui9kA9Kp7oIRw+NrhcVUE7h1r3kXhUY56ig4AJ7i3CGDxRu1KE5Rn24izbmSoyy7 Ilvc5gdOTxQFFWkixsRxRqSw8D3MODJobNvL0RBLD1stSu+6VDlFZB7pJmPGJYL842oe imY7Osy87cFfeF/SQuyLIwtTY8zl9yrtoHXDA+dQyiKQkOM4ZzNhfuxYvyeNnPsgBv6m xVnStsK39ktGOF1nBch8R0kCEYYZoj5e4R55C8Mqh55mijsW4zoRMXcO3ZFj47+fGPMI M3yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=gffaBbcofeeFiBhNAZzQqlyqYLYP0+7p/4lHz0R8tfc=; b=mUyt1N8Np+f73vOhYoycZ6mBh0f7sFdnnxIA7IO/SIryxl1y+S/cZTY/kW+1L1isup 2E5xd4ldfeJe/Cco1Slz6d1Ebcir/LP+dgAdPFSjlvG4xULy+5uU862YL/yjnFguSz2R WB8dqkaFEEz6BQI0+5IYK7VHfnrm8QzyRecq11YJ8SjSaP2dErwEqaMIpnsPE4yWDq6o sw94fjfTBMFNPpQuM4DLqGC96cSwlHHyA6Jl1zhhGznofApyX/0tMtVWb807uk17smx8 xL9haJEEBtocpiv62UF5cLYXf/fA4QPM6yaaKq4erQlgU/lQVsp4CmMzflXc4tvWOXUP Mmig== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=flKzyq0g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xb13-20020a170907070d00b007c1600359ecsi36887623ejb.441.2023.01.18.04.17.34; Wed, 18 Jan 2023 04:17:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=flKzyq0g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230118AbjARLsA (ORCPT + 47 others); Wed, 18 Jan 2023 06:48:00 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52898 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229947AbjARLok (ORCPT ); Wed, 18 Jan 2023 06:44:40 -0500 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C74336B3F for ; Wed, 18 Jan 2023 03:06:51 -0800 (PST) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 475D720C28; Wed, 18 Jan 2023 11:06:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1674040010; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gffaBbcofeeFiBhNAZzQqlyqYLYP0+7p/4lHz0R8tfc=; b=flKzyq0g6ztoMc7rANkxAYuT0tb4jrl51aFnX3C+UXTBi0yrEOhANriYnZ55Pp4IDxwgir 4fd6uLbXKGIp1LP9aT/Ax6r4atEEqjEJRCRm/RvclMlzQ4seeVe4HuV15gTEoPCOe+teuX yfMy7DcgE5G4fNvDQVQwZmXMi/SlnoA= Received: from suse.cz (pmladek.udp.ovpn2.prg.suse.de [10.100.201.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id C27032C142; Wed, 18 Jan 2023 11:06:49 +0000 (UTC) Date: Wed, 18 Jan 2023 12:06:49 +0100 From: Petr Mladek To: =?utf-8?B?5byg5YWD54Ca?= Tio Zhang Cc: Chen Yu , Peter Zijlstra , Vincent Guittot , Ingo Molnar , Juri Lelli , LKML , Yuanhan Zhang , "zwp10758@gmail.com" , "zyhtheonly@yeah.net" Subject: Re: [PATCH] sched: print parent comm in sched_show_task() Message-ID: References: <37FFCAF0-B0BA-48BD-B688-B1C5E7A10A1A@didiglobal.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <37FFCAF0-B0BA-48BD-B688-B1C5E7A10A1A@didiglobal.com> X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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:; or pr_info("parent:???\n"); or pr_info("parent:unknown (task is exiting)\n"); I slightly prefer the 2nd variant. The string makes it rather clear that the information is not accessible. And pid_alive() actually does: return p->thread_pid != NULL; Best Regards, Petr