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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8431BECAAD3 for ; Mon, 19 Sep 2022 14:43:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 194706B0071; Mon, 19 Sep 2022 10:43:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 11DC16B0072; Mon, 19 Sep 2022 10:43:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDA49940007; Mon, 19 Sep 2022 10:43:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DBC936B0071 for ; Mon, 19 Sep 2022 10:43:06 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id AD9A8C1183 for ; Mon, 19 Sep 2022 14:43:06 +0000 (UTC) X-FDA: 79929102372.21.E2444C8 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf02.hostedemail.com (Postfix) with ESMTP id 4464480003 for ; Mon, 19 Sep 2022 14:43:06 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B104221F82; Mon, 19 Sep 2022 14:43:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1663598584; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MmGdRLJbXKoDHbtEsvS6wAys9F3jM3Uxx+Jt2KN/6yI=; b=bXiQD6KCrnLA+lwffE4pfxYaL//UVqTOB+6Q5NAWsdHWR+F1oNCfopQ19YqfTi1PF+egOL bcApiIW8isBRqOyywK3m6AW2d9Vp6Jf0ZWw+PG1TDaZotAayVAzS4eDPsFoyXLX5Cu/26v UdE8veyK286pLW2t79LP5GQtS9YWLk0= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 9373813ABD; Mon, 19 Sep 2022 14:43:04 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id PvmvIfh/KGPGZgAAMHmgww (envelope-from ); Mon, 19 Sep 2022 14:43:04 +0000 Date: Mon, 19 Sep 2022 16:43:04 +0200 From: Michal Hocko To: Pratyush Brahma Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, quic_charante@quicinc.com, quic_pkondeti@quicinc.com Subject: Re: [PATCH v2] mm: oom_kill: add trace logs in process_mrelease() system call Message-ID: References: <20220816060017.17996-1-pbrahma@qti.qualcomm.com> <20220816173556.cb493d6a85edd65e1fa52911@linux-foundation.org> <1326361c-44c3-d2e0-c7a9-1e4b3e84ab6e@quicinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1326361c-44c3-d2e0-c7a9-1e4b3e84ab6e@quicinc.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1663598586; a=rsa-sha256; cv=none; b=1aO0HSv6YaB0M+CrTSLAauzPf9AP+Bwc23ov8tUnFW1oD1FbjXSmMIDtlYjaqRPbe2zWRe 0Adjo0G9bQY1h9WWWu4YQlJsyPHs4RU97T27mAVzUWAmc2TXIOSvzR6ekth8cNme4vHGDm Os/nO9LRsde3tfVqRg/teB+ydq87qbc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=bXiQD6KC; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1663598586; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MmGdRLJbXKoDHbtEsvS6wAys9F3jM3Uxx+Jt2KN/6yI=; b=W5f0SBO708UqP7yAGGP2dHprMl6+YsMoNODrNSQLMQUntDy/fR6F1/IQAWOHphSJCcn1EN pGUeW3u0ObvuHlNetTTUHC1lVFDNjMMBVHLmiicUBRvNZkqZJT3MUHHFGWvhubYt/WdJ0M soYKPTrXl3evXTkBoEWe254KwjFutOw= X-Stat-Signature: snm5ickcgso5q37ecipfpkxsxczb3iao X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=bXiQD6KC; spf=pass (imf02.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 4464480003 X-HE-Tag: 1663598586-427531 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 17-08-22 12:17:22, Pratyush Brahma wrote: > > On 17-08-2022 06:05, Andrew Morton wrote: > > On Tue, 16 Aug 2022 11:30:17 +0530 Pratyush Brahma wrote: > > > > > The process_mrelease() system call[1] is used to release the memory of > > > a dying process from the context of the caller, which is similar to and > > > uses the functions of the oom reaper logic. There exists trace logs for > > > a process when reaped by the oom reaper. Just extend the same to when > > > done by the process_mrelease() system call. > > Why? Please describe in full detail the end-user value of this change. > > This patch provides information on how much memory is freed from a process > which is being reaped. Adding trace events in the process_mrelease() path when > process is being reaped would enable more holistic debug as it happens in > oom_reap_task_mm() currently. > > This extends the debug functionality for the events as described in [1] to > the process_mrelease() system call. Now the coverage of trace events is complete. Yes this is all nice but why it is needed to extend process_mrelease to be in par with the oom path? OOM path happens out of direct control of while this is under direct control of the caller. So why do we need more debugging data from the kernel? The information dumped by the tracing can be queried already by other means and much more extensibly. > [1] > https://lore.kernel.org/all/20170530185231.GA13412@castle/T/#u -- Michal Hocko SUSE Labs