From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1507AC433B4 for ; Mon, 3 May 2021 16:31:18 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D748A61166 for ; Mon, 3 May 2021 16:31:17 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231280AbhECQcJ convert rfc822-to-8bit (ORCPT ); Mon, 3 May 2021 12:32:09 -0400 Received: from out01.mta.xmission.com ([166.70.13.231]:51504 "EHLO out01.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231305AbhECQcG (ORCPT ); Mon, 3 May 2021 12:32:06 -0400 Received: from in02.mta.xmission.com ([166.70.13.52]) by out01.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ldbTI-00Guxb-V2; Mon, 03 May 2021 10:31:01 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=fess.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1ldbTH-00DUxX-C4; Mon, 03 May 2021 10:31:00 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Cc: , , , , , , , , , , , , References: <20210430142223.25500-1-peter.enderborg@sony.com> <20210430142223.25500-2-peter.enderborg@sony.com> <4bb24db4-f720-f5e7-9054-36bdeaee1d79@sony.com> <20210501091104.418765bd@oasis.local.home> <1214833117.22933.1620049830326.JavaMail.zimbra@efficios.com> <769a00d2-a76d-62d2-aa56-5a107dfdc53d@sony.com> Date: Mon, 03 May 2021 11:30:55 -0500 In-Reply-To: <769a00d2-a76d-62d2-aa56-5a107dfdc53d@sony.com> (Peter Enderborg's message of "Mon, 3 May 2021 14:48:33 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT X-XM-SPF: eid=1ldbTH-00DUxX-C4;;;mid=;;;hst=in02.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/cM5lP+LtEYh/PUB7WEiMxI5uS5CjEhCQ= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 1/2] tracing: Add a trace for task_exit X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org writes: > On 5/3/21 3:50 PM, Mathieu Desnoyers wrote: >> ----- On May 1, 2021, at 9:11 AM, rostedt rostedt@goodmis.org wrote: >> >>> On Sat, 1 May 2021 09:29:41 +0000 >>> wrote: >>> >>>> On 4/30/21 7:48 PM, Eric W. Biederman wrote: >>>>> Peter Enderborg writes: >>>>> >>>>>> This is the peer functions to task_rename and task_newtask. >>>>>> With this we get hole "life-cycle" of task and can easily >>>>>> see short livied task and their exit status. >>>>> This patch is incorrect. The location you are dealing with is not part >>>>> of task exit. The location you have instrumented is part of reaping a >>>>> task which can come arbitrarily long after the task exits. >>>> That is what it aiming. When using this as tool for userspace you >>>> would like to know when the task is done. When it no longer >>>> holds any thing that might have any impact. If you think the >>>> exit imply something more specific I can change the name. >>>> >>>> I thought exit was a good name, it is in in exit.c. >>>> >>>> Will the name task_done, task_finished or task_reaped work for you? >>> I think "task_reaped" is probably the best name, and the most >>> descriptive of what happened. >> What would it provide that is not already available through the "sched_process_free" >> tracepoint in delayed_put_task_struct ? > > For task_exit (or task_reaped) > >         field:pid_t pid;        offset:8;       size:4; signed:1; >         field:short oom_score_adj;      offset:12;      size:2; signed:1; >         field:int exit_signal;  offset:16;      size:4; signed:1; >         field:int exit_code;    offset:20;      size:4; signed:1; >         field:int exit_state;   offset:24;      size:4; signed:1; >         field:__data_loc char[] comm;   offset:28;      size:4; signed:1; > > sched_process_free >         field:char comm[16];    offset:8;       size:16;        signed:1; >         field:pid_t pid;        offset:24;      size:4; signed:1; >         field:int prio; offset:28;      size:4; signed:1; > > So information about oom_score_adj, and it's exit parameters. For the record returning oom_score_adj that late is not appropriate for any kernel/user API. It is perfectly valid for the kernel to optimize out anything that wait(2) does not return. If you want oom_score_adj you probably need to sample it in sched_process_exit. I periodically move things from the point a process is reaped to the point where a task stops running, for both correctness and for simpler maintenance. When threads were added a bunch of cleanup was added to the wrong place. I certainly would not hesitate to mess with oom_score_adj if changing something would make the code simpler. With both sched_process_free and sched_process_exit it looks like we already have tracepoints everywhere they could be needed. task exit. Eric