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 C6697C48BF8 for ; Thu, 22 Feb 2024 14:16:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5784B6B008C; Thu, 22 Feb 2024 09:16:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4FFE76B0092; Thu, 22 Feb 2024 09:16:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 379456B0096; Thu, 22 Feb 2024 09:16:19 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 2040A6B008C for ; Thu, 22 Feb 2024 09:16:19 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E46DE1C0F4E for ; Thu, 22 Feb 2024 14:16:18 +0000 (UTC) X-FDA: 81819639636.03.7C6F32B Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf07.hostedemail.com (Postfix) with ESMTP id 8112340013 for ; Thu, 22 Feb 2024 14:16:15 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oaz+50pm; dkim=pass header.d=suse.com header.s=susede1 header.b=oaz+50pm; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1708611375; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6lq0D1Zv9ew5MQu6n3pDdGjgwnsaGgA0IKlZXqZNnek=; b=upA9m0J5/JoxEd54eRZ02OYRkJgY/76ouyuR8sGmYpU3qTP0U1tO0SAv1Uw9qYmCxbEvNz 2R9qayHJ+TjuhL5MjZZ4W3qqtMK022Is+JQLP2X4gwAGuGggF+s3e0qmiDY2wO8yIv0RoB TKEobUMNkgxohKz6XFCsanQjXfWxsow= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=oaz+50pm; dkim=pass header.d=suse.com header.s=susede1 header.b=oaz+50pm; spf=pass (imf07.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708611375; a=rsa-sha256; cv=none; b=oOU5LUSEJVMMTse9wqycML8u8pm2YwqveEoW37oNi8Jk/MrtN7HoCfTUNtz3MlQOgpNQ8P NQNKFD02vFe/a1RyQgRtm9i8ohqhCjgT4+Acip2XFU3bcscaE/2f2B65qAGJfZXPrmMQsS +lVinvSsFY1IfxoL5C2c4emm7Q5yjRo= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id AF6F72119A; Thu, 22 Feb 2024 14:16:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708611373; 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=6lq0D1Zv9ew5MQu6n3pDdGjgwnsaGgA0IKlZXqZNnek=; b=oaz+50pmopgSUHIy0b7fFO06fBh7nbKQaNZEVUYhzuhKcKan5Z2rCMdGKyKl440M1i8qCt tmRTJwgKKPsb7Ka/0b9zM1R4pPJeECfw0KEDJ5v/OWHX3gXs3gv5lVwZk6xlf5M2oj49wP RQ+Mql8nwDBFbPSrkC5I6NNhExD0tPk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708611373; 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=6lq0D1Zv9ew5MQu6n3pDdGjgwnsaGgA0IKlZXqZNnek=; b=oaz+50pmopgSUHIy0b7fFO06fBh7nbKQaNZEVUYhzuhKcKan5Z2rCMdGKyKl440M1i8qCt tmRTJwgKKPsb7Ka/0b9zM1R4pPJeECfw0KEDJ5v/OWHX3gXs3gv5lVwZk6xlf5M2oj49wP RQ+Mql8nwDBFbPSrkC5I6NNhExD0tPk= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 8BB09133DC; Thu, 22 Feb 2024 14:16:13 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id 6iQWHy1X12X7RQAAD6G6ig (envelope-from ); Thu, 22 Feb 2024 14:16:13 +0000 Date: Thu, 22 Feb 2024 15:16:12 +0100 From: Michal Hocko To: Carlos Galo Cc: rostedt@goodmis.org, akpm@linux-foundation.org, surenb@google.com, android-mm@google.com, kernel-team@android.com, Masami Hiramatsu , Mathieu Desnoyers , linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm: Update mark_victim tracepoints fields Message-ID: References: <20240111210539.636607-1-carlosgalo@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Queue-Id: 8112340013 X-Rspam-User: X-Stat-Signature: kgzk6hbxuewybwjf18wpqpysm8z11qhm X-Rspamd-Server: rspam01 X-HE-Tag: 1708611375-399502 X-HE-Meta: U2FsdGVkX1+SxJo15AbnZSGeiXsSvXT8vsXSegukIsnWGl6FRDLLTd+BONsmym0JNsJKgNneVLVjjKjGGodsxpdCxqtLydmNUyGVn8IEzh9Z4oQEqT9FLraPqgpQxWCekryyX0Ycf4LmXWUEvX2sE3aR4KTgeVGHgj7rFFnj6qeydPDJnP0nUpWYYW1wpLmn7cz6fnA/VZpa3y9hPVcuOyN8PpPCcGYGgwNJiB68DlPE1InjMJLqDSUcA3rZurmM656ocRWaHPu5nuwz/LY7voIxEqz07aK5Z5nmJiTA8L/GOT0jTQpklxUws840ufpOUowbi5AER0MtuW8t2rnBqeFneI0YCaBpT1z1zQx0b4JcegVpQ+qJV+2qMK6PieUR/53j8Hc6fA7HM7tVsS8TFP8fUBrp80GE3wYSVRxgAh/a3MNYvTKLSmqc1omtqeSdmb+w4p/0ggqmx9dwdO6Rbz54F6VpM+RhED0RP4StLk/b1qU8xvDMBgGqrHili7t97WfKNAHxxmuTtLRMc7nmnl9QixdoNOExBeKftFF30ga7VUxTZTZUx9Eba3DFyDE0+gs/U7SGc2v9KQ1V13mADDEhc/vXA3tkw0BkW/wNmxKBpwszd6iOAtlVxS3OutCEovPz+vQsdD8n6GAhz4pM/7ekN388GpNk2bXIGoWko87xb2RRHhQsoJMQ8b0VShsGqY4OdIyOSoRKuRl6jXel403NusQ5eEd6KV7br4rYbCGZkw/7vswp26AUuKjwFEw9AhxX3hXln03ZFbpgcns128KwUgvcpp6d4J3lD5YTd8pOIqNJj1V5JyD+PyEtQpVpxgNQl82BISPhHuszbKNVN1IuZLnQZYtA5xDUmgIhrb2wl5Vmjjf13EC4GcSf7c6yAoxKLkDRAS0TsR3Qhzund4v3o0QM5usdZjrqb1sRZE7hk7LCMgRucA0jmZ8U8QCaLapfW0crB7ibuJEW2Oo /t6N00Kk T4jRaULTv1ZO285g2PGmawdIvEZNK6fp/ZOi3WXafcJnnnX5uFL+4aOWPdDrd1xQMBpWIxTBlKYFzwZajnAugBC7Unv+j/E98KCUFYvpf/Gj4YD+6IXdgm0AzF8STN8hqYP8SzMNimsNycnd0iULPVQ7thGNAC9k9tPwIwsaQ8Tr04U6409rNCW4NVleK20iaTj4aI0VltajpqfQdrLyRJMyEtnKST8Y++Crra/y/KwfRHYwigP1/zLsipuBLCI9SvZONYFlH/RDs8KeKe370Fb31YoqXmlxo5zeyVv/n/IvqNK7h6o3M16JMP+JiMoMm5qc3 X-Bogosity: Ham, tests=bogofilter, spamicity=0.182897, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed 21-02-24 13:30:51, Carlos Galo wrote: > On Tue, Feb 20, 2024 at 11:55 PM Michal Hocko wrote: > > > > Hi, > > sorry I have missed this before. > > > > On Thu 11-01-24 21:05:30, Carlos Galo wrote: > > > The current implementation of the mark_victim tracepoint provides only > > > the process ID (pid) of the victim process. This limitation poses > > > challenges for userspace tools that need additional information > > > about the OOM victim. The association between pid and the additional > > > data may be lost after the kill, making it difficult for userspace to > > > correlate the OOM event with the specific process. > > > > You are correct that post OOM all per-process information is lost. On > > the other hand we do dump all this information to the kernel log. Could > > you explain why that is not suitable for your purpose? > > Userspace tools often need real-time visibility into OOM situations > for userspace intervention. Our use case involves utilizing BPF > programs, along with BPF ring buffers, to provide OOM notification to > userspace. Parsing kernel logs would be significant overhead as > opposed to the event based BPF approach. Please put that into the changelog. > > > In order to mitigate this limitation, add the following fields: > > > > > > - UID > > > In Android each installed application has a unique UID. Including > > > the `uid` assists in correlating OOM events with specific apps. > > > > > > - Process Name (comm) > > > Enables identification of the affected process. > > > > > > - OOM Score > > > Allows userspace to get additional insights of the relative kill > > > priority of the OOM victim. > > > > What is the oom score useful for? > > > The OOM score provides us a measure of the victim's importance. On the > android side, it allows us to identify if top or foreground apps are > killed, which have user perceptible impact. But the value on its own (wihtout knowing scores of other tasks) doesn't really tell you anything, does it? > > Is there any reason to provide a different information from the one > > reported to the kernel log? > > __oom_kill_process: > > pr_err("%s: Killed process %d (%s) total-vm:%lukB, anon-rss:%lukB, file-rss:%lukB, shmem-rss:%lukB, UID:%u pgtables:%lukB oom_score_adj:%hd\n", > > message, task_pid_nr(victim), victim->comm, K(mm->total_vm), > > K(get_mm_counter(mm, MM_ANONPAGES)), > > K(get_mm_counter(mm, MM_FILEPAGES)), > > K(get_mm_counter(mm, MM_SHMEMPAGES)), > > from_kuid(&init_user_ns, task_uid(victim)), > > mm_pgtables_bytes(mm) >> 10, victim->signal->oom_score_adj); > > > > We added these fields we need (UID, process name, and OOM score), but > we're open to adding the others if you prefer that for consistency > with the kernel log. yes, I think the consistency would be better here. For one it reports numbers which can tell quite a lot about the killed victim. It is a superset of what you already asking for. With a notable exception of the oom_score which is really dubious without a wider context. -- Michal Hocko SUSE Labs