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 8C8FBC48BF8 for ; Thu, 22 Feb 2024 17:59:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 11ACB6B0082; Thu, 22 Feb 2024 12:59:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A4476B0088; Thu, 22 Feb 2024 12:59:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E868A6B009C; Thu, 22 Feb 2024 12:59:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D3AB86B0082 for ; Thu, 22 Feb 2024 12:59:50 -0500 (EST) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A943B40B8B for ; Thu, 22 Feb 2024 17:59:50 +0000 (UTC) X-FDA: 81820202940.24.4548E57 Received: from mail-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) by imf28.hostedemail.com (Postfix) with ESMTP id B92AEC000E for ; Thu, 22 Feb 2024 17:59:48 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="FUiVp/UM"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of carlosgalo@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=carlosgalo@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708624788; 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=lAfh0deUlctQewLM9rYvzLmpV0jruOlVqgBOdUhaXcI=; b=roQnoxuw9D21biHZcccaOyjjCaLKgKVbd8RxiVcW9mMV5dC51eiu6KoVQKZn39wpO/KfAN jw4zlljP49YNF8cVS1HYGcpu3sVSleLvdrYXt5t3pU1kfHDjVEiAPVHvipgEg+OHyvagDu 0KbBsRTNqnIX7Eh60ct1oDphxNtqcEE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="FUiVp/UM"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf28.hostedemail.com: domain of carlosgalo@google.com designates 209.85.222.43 as permitted sender) smtp.mailfrom=carlosgalo@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708624788; a=rsa-sha256; cv=none; b=7g1iV1P1rdaqy1Rv6+RRiAd4IoQ5bFeZ0xLAALunIWlIMa8+L3CO35ClRwqaE5hlkDYP2B W3nk3QRZvzY57chhMC8nGchbPhAVH59wMME4SerUr53JdNjloanBwWyppV0Mp2PdlltOiZ RqdbgjRNkHgfJ9LST+jiImE/duoyQAU= Received: by mail-ua1-f43.google.com with SMTP id a1e0cc1a2514c-7d2e19120b5so4475405241.2 for ; Thu, 22 Feb 2024 09:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708624788; x=1709229588; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=lAfh0deUlctQewLM9rYvzLmpV0jruOlVqgBOdUhaXcI=; b=FUiVp/UMUCt4yiff7eqhA3cl4AJMxDNncW/NZtpHxfTjndaTfYI2Ip5Lh+5haxiLnw TZWxTaPFSfD4HJZuf+pJVT8AeFOjJUSTQSKJEDrwZfne7JV5NVjIIE0/OFQ8ydpgQ39w RY5WiaAd3Pqr531ii1bdhr/WfvCEeQSBStJzQ4ZScvUFk2ewe0H/YwXoTuxGRIXpvKLb Swi/arVa/iB//Gqm2RgoI/zxeQQH62cvdqwIvYJI3WRPV1Hp+FdHxDxfbZx457VHdn/C hJSLkYy8qRj2FcFUqC33Ah9dr1JvnVJn6heUhSj8pL3OtFP2sYzO9rcpJmfwCf3YpAz/ omPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708624788; x=1709229588; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=lAfh0deUlctQewLM9rYvzLmpV0jruOlVqgBOdUhaXcI=; b=H6SnTc3mFsEEpE3vBJoxm6cKNa15ELxifTS5JZMpeCZDi/qtYjt4HfvoiW89HydXBT vtmlbf55HwG5SrcNZpRNgt7jDvpOjTzZR0rrt695vIU84hG32sBLPjCvTz19SAS5Ro/3 dBOptkW2z36Q/PYeJSEx41KLuhG9grmzZRCtGjPRe2WGtXv3hGEFNTVEvgp+7s0JB0PB yhHVFZoXgWNCPwp9Eshs6aqB4f9/G3K0tjAAhrIYKyaECKv9j5HrlsdfZcbFZZU/08RG B0ZaZjpTYqo6y/qWPRqGNCgOstTHPGJBIfgfqnOOADKfp42752VRHhNOUgFEA5UouSqQ Gu/w== X-Forwarded-Encrypted: i=1; AJvYcCVHjOt6GQ46rpqZK0emyXbwDsFXkmHTKkeKI5kEe23k51VBKanRKfvkuxQG7IUNFrBPSm1HO08kAidsaAOq5YBKabc= X-Gm-Message-State: AOJu0YyDpEtg1V3z1a81tCWhXM2xNEdhaxmOkCy7PsifEoFQdOzU4EjE b7ucNFpm4Tdfmdg7JkZqf26ATpY8kyuQugRPBfE8g6xLognkfp2qLa8/+ZlekbtCzIAD9ueBW9N hAlhF3iLH3VjUrppNlqyatvQrq867Cl6EWDWl X-Google-Smtp-Source: AGHT+IFAcQHAiZ1fQ8mfYjH9A8yIg25e7KdgVRcZ1st9GcOueJ6vRhI4a0/vUzUq8j3sQqvTbwrNpNPCpjk0U2FyxTo= X-Received: by 2002:a67:fbd3:0:b0:470:5fdd:d5c with SMTP id o19-20020a67fbd3000000b004705fdd0d5cmr12228729vsr.31.1708624787593; Thu, 22 Feb 2024 09:59:47 -0800 (PST) MIME-Version: 1.0 References: <20240111210539.636607-1-carlosgalo@google.com> In-Reply-To: From: Carlos Galo Date: Thu, 22 Feb 2024 09:59:34 -0800 Message-ID: Subject: Re: [PATCH v2] mm: Update mark_victim tracepoints fields To: Michal Hocko 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: B92AEC000E X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: dyda1ornjqkz484hr9as4dd1g43qtrem X-HE-Tag: 1708624788-779345 X-HE-Meta: U2FsdGVkX18WVK2uiDLjQ7WLeiOub2jLYc/WgP7b3SsjJasehKiUXwCQFaeGB39P4gbEwrhBkZOgJTVN+h8gUevPXTJdD9F9O+ie9Xn7DGtSsrknXu+921CP3KRGfyKRhsI0aCNT69qW/PQbYraBR/gRaAJhTs9RosSkOYckVOFM2+ExQsxL2ovbpQjeHi9Lqo+K6wFI3RdZRou8sA9Go4GoZ7UdGVsGO9h9MkP5AGqjjJS1Lzz2mY7KKRF0qqfGChk9duwMc5yIaAxVxyjp7V5EdnCmrUVAPPiKbRSUJnWok2Ubblz9GK4o++66bQVtpGHJsFqvQsd6aB8weX91NfSIznOadH2o0onMqTCRC6yi/UrBC3hBn8otSyMWA8nz6LmGfc8M7hehtpCbCtfIuvwHs1M+mVoL38gQQRmdasJAcg46K2VMoovT/Cgf+CIpbq0K44mEFGH6tUgH0w2xyprEniC3borCTg2t/16J56HN1k9jq2RWXQ8PjLgc9dVA3drT7ldrDVhSMKbHHdPkILLoRjVNpeyoxuoCGPxadMgCQtRJUlnDilBM7ujdbVmzW+xbbyBB0hHycJuYwO6TyhGRMf3O6wjOxMCEtHiC8TM5ry7IKpBaTc17nbeTZVo/cw5y6XvJYBV0O/DCrDhX+KRtQmGtgcxQX4hkdHen1dfkHS5ca7mBv0HWDpEEkLMWS9KkLv/kWTSgfhusxTWDxRo/n3ceZlbpZ2Oynw+4D64ZaEQIseHrEBKA8m9RknqwSFXXjvKF5JJpCv/ZJceByhT8swsKYoKVvaBy9htz0Vxh8mV+r8U0lK2cdyM76JbbRJ1XajY+uXiyGmE2jkhgiGSW/3oktyxVmw05nAIIbzu9YUXL0hmKB+ClYmR74n2Kn7ChGD5GeDhXiu6Bax+oTotCqj316F3DgJZGo7QXtMqPRjznqPZSvcqWks/CA62oT+qK+/GY3OGHH9FHn56 FMl4P2gV hkX8VVsIomDotQxbFxdxjr+CbOkJPfNy7bNRYYPlG4m+AOglI+l9Bm+3a9U0bfg54WAmltYmTmy1sZKQmc2S0ewxeUvTLBkRBoCvs0fiDggfRcYjrOrybyCXm6c4XJjj5IbNugaAIMNVWt0DwZ55ubuZeESLnEobK4nml7ptEMKgJG+kOvJn4W0CpAdpcCL3TU9D6TuFNF2VWdWUVzdciUnAku76fHCMD9ME1kckutCux1vbM83ItNNIsGplsXiDC2S0xaZYX45Htw+5M+AK45E9gMuLRFOW5bD82fmOAcFYOplIcsabzmwcWz4G5ByeCylEmBoXwWZvcVMw= X-Bogosity: Ham, tests=bogofilter, spamicity=0.436594, 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 Thu, Feb 22, 2024 at 6:16=E2=80=AFAM Michal Hocko wrot= e: > > On Wed 21-02-24 13:30:51, Carlos Galo wrote: > > On Tue, Feb 20, 2024 at 11:55=E2=80=AFPM 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 o= nly > > > > 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 additiona= l > > > > 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. Cou= ld > > > 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. Will do. > > > > In order to mitigate this limitation, add the following fields: > > > > > > > > - UID > > > > In Android each installed application has a unique UID. Includin= g > > > > 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? Android uses the OOM adj_score ranges to categorize app state (foreground, background, ...). I'll resend a v3 with the commit text updated to include details about this. > > > 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, fi= le-rss:%lukB, shmem-rss:%lukB, UID:%u pgtables:%lukB oom_score_adj:%hd\n", > > > message, task_pid_nr(victim), victim->comm, K(mm->tot= al_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_scor= e_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. Sounds good, I'll resend a v3 that includes these fields as well. Thanks, Carlos > -- > Michal Hocko > SUSE Labs