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 60ADDC3ABB6 for ; Mon, 5 May 2025 08:08:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DDE1D6B008C; Mon, 5 May 2025 04:08:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D8CB76B0092; Mon, 5 May 2025 04:08:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C52566B0093; Mon, 5 May 2025 04:08:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id A747A6B008C for ; Mon, 5 May 2025 04:08:57 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 222ADCC88D for ; Mon, 5 May 2025 08:08:58 +0000 (UTC) X-FDA: 83408128356.14.7CE93BD Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) by imf16.hostedemail.com (Postfix) with ESMTP id 19F6E18000B for ; Mon, 5 May 2025 08:08:55 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LWIOc2UR; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746432536; 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=ih3NqDpNYxVnwTqQNjr/HduzzcPs128fQGA7XiiKKbU=; b=KjbuggHmjmy4x8VfI0MU3pSn2jIdBy2/olGXd5NOvSv080Y17C20xOI3XwVVotA0BwWI+W /qrs7ewa2wU3Yhpz4y4mKc/TmDNgy6CB6V7AwFu4k6bHN+ZuGKjERWmBoaEVHdzU60Y+FX Rn2IyQuj3S0x5YWUGWSJUK77/YJ+FHA= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=LWIOc2UR; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.52 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746432536; a=rsa-sha256; cv=none; b=Sowhrev0mILBvy8gVS6Tmrkrx27WHAEfec0NjNeiqRV/BhGzkU40sHMjkYJ45WBqWS0ugK uRWJUxiLEe2os1DrhjrpVC4iWq0rHqI5PFzi1LiBobi4mJplHrAV4hAF1IzfeMr9cN8gEm 7zb7m1ivvBP56NcwfECatSsyUEb3JRc= Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-43d04dc73b7so34430305e9.3 for ; Mon, 05 May 2025 01:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1746432534; x=1747037334; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ih3NqDpNYxVnwTqQNjr/HduzzcPs128fQGA7XiiKKbU=; b=LWIOc2URQJhoPhRVAVo1vgR4CjWSdWztiXZLtIdnEsM/GD/BE4PJxpnKJ71iD/cTOI wifIn9rZUmL2k9M90+3rHpu6FTsNJ9yYm2S0U9ZVVADIkbOlhKT0RF8UZleDwGbPk9ow 4t7EaTd4FMgBAslbkqfnMV6karY+cqvThiVTZ3+tHQWWheNDbEA39DoVxkIZc7zKovv2 JJqc+Rp3ftz74TuPTsTqs4BmTUxDcFI2tTuxnz57+TLWv7j2iiddiKzGPzABqTpISppf i0pjIrDRE+xlbl+YoQtNcFzST6X7A4LOP1uLi2/zkd8Gw1H8R6y91/S0FF4b6my5kEVM 8IlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746432534; x=1747037334; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ih3NqDpNYxVnwTqQNjr/HduzzcPs128fQGA7XiiKKbU=; b=w3yJbNNMPqAwqgueX9yZ/9NkSnSU0GUnfGVWhyL5vxyPuJjE03sKF2UGZzZmM7/CGL Gdg7jxYM83uFxvxoc1emnYldiPs6wX96ocY4kp0Xv3DxTCJQfrRZBi01nwAOyuZGDeXQ 1YJ7MiBc5fFdNZZGd7I4Sha1xDjxcr7oc9/HlvQEOSVse+lXCJ6kfCDKU3oDpZ1bdJTL EQ32Nn+zHPSGMDvrmHUVWPNUYSKTJ8w+ZUZ0/re5Fb+7n7LMC6kewjyEbfd8wq+As0Fo c2rkLPWNgqq3EbdAkAcj/Pv1clZXpAxMDa7w3+qK35fj1X2zR4DmbW8R0yxznHTi6EP/ pFDA== X-Forwarded-Encrypted: i=1; AJvYcCX5QI8nvzvJlcMQxQFY8Z4BcSShhNT4phDdTw07qtHO3CX1Ib2W1cp30CBNRTJCtyqXHpJcKspoNA==@kvack.org X-Gm-Message-State: AOJu0YxekBFQHWwjhp3UJyTF2arJCjsbCq16/TJksGlUDWEXrK/Inetz +BetJup51ZU7vougH9Ng302OiPsvOOjt8FZn4mrQOhsx7ZWv0+YiC9ygFfPEnI8= X-Gm-Gg: ASbGncsRyDa4Q8aM+6MjXe8Oi/QvD3qUJAChdm7ZadQ3I3A1v4SO3VqM9+cEy/Fxg8f 7SK/UHfehOBtoSQQz4qcmsDdZT1dZo4uHSivmZShKnHSgulxQJHgZOmXnZfT5/mT3/8/pLJWNVG v15jRU/EYNujpatlQgTeRO7Ts6mAjNADtgb7dVDPEWp/5dV76zIMeVvAl5Xhw3GF+0M/kCPGa4I rxt/oDUZWc0oWRs3JBmHM+/CLnW3R9N6b0sH+wK0W8eefnQPT+zTouuhEtT8ioYu8V7AaPNpjRa x7TmhBjYB1wi73O6f+qf2G+mV/+sZU7mrVsPw4hZBg9/wEoAQnA= X-Google-Smtp-Source: AGHT+IEurvdHsB2rKDl3Rsu/uufeIj/T+2DXVXCdsFmbDaGBcEViq6YlhktTwiTRJwVY7SSU0p4HUg== X-Received: by 2002:a05:600c:5124:b0:43c:fe15:41cb with SMTP id 5b1f17b1804b1-441c48c1d07mr44823985e9.15.1746432534171; Mon, 05 May 2025 01:08:54 -0700 (PDT) Received: from localhost (109-81-80-21.rct.o2.cz. [109.81.80.21]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-441b2af4546sm172441785e9.22.2025.05.05.01.08.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 May 2025 01:08:53 -0700 (PDT) Date: Mon, 5 May 2025 10:08:53 +0200 From: Michal Hocko To: Roman Gushchin Cc: linux-kernel@vger.kernel.org, Andrew Morton , Alexei Starovoitov , Johannes Weiner , Shakeel Butt , Suren Baghdasaryan , David Rientjes , Josh Don , Chuyi Zhou , cgroups@vger.kernel.org, linux-mm@kvack.org, bpf@vger.kernel.org Subject: Re: [PATCH rfc 10/12] mm: introduce bpf_out_of_memory() bpf kfunc Message-ID: References: <20250428033617.3797686-1-roman.gushchin@linux.dev> <20250428033617.3797686-11-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: gjf84tkr5r1fqs4zrzert71mm9i9ocao X-Rspamd-Queue-Id: 19F6E18000B X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1746432535-980516 X-HE-Meta: U2FsdGVkX1+y5hlMG0BmznMa3SAP2ufucZLXtuZjerciuhHxALnadGiiIs4WZSXBCsI4GmC23QztWcxFWrbiyWvwTWpRefclhVgJAKPo58DP+4devTPYTWBtq9g95sQvNCsmm+IaJ7KLBgkKPcsxVF4o9bKE/NgNDhK5mRAL/NIM8msENcGyfMixzrdjj1/Z5j+KlYh7fDM1y9EF0pfpgxEUrVlE+TRwb9r5dYbkJ7oHNfDrw60y0bQ4JiM15k2HlS12+kY8quuLYxJ1gwTi1CTXadDDW85XRVyLWTNpQtBcHAhZOSlh/JKQRT2sFLXy3ChcMTq4RS+gmao8+w+nGhWMGUFYRhOM/dtJ1j7FevH1TrV2LtBRfis9U8CuQtt/5rM2NVWODJznMObIcTDOui3Gmgmy1cX5mnj7VHlr5GuxunY4ZTn5gG/XrJZJooZ5Bnqig8va7TnzOJzhtAodyWLXb6033DKIJK+EHCEhnSLQbZaFqJb0O7g7IQbEiLzwm/ABifJd7qHCMks3CBEXj+rUPnyRiC+tiLAVP3g/jx4iClBw47AoXNJn0nWDvnG870bxs9YMD4HrwQmd727yy3ELddVm+EzO2Nukzql0krwFv/5CIrld27P1IRBs8lRc6gGIPM8EBoALP/7jYMvUuvcqckLFz2cURdLwQNDrWDm24EuJfPxN/etV6wHGNvmkYrtft5bE67FWf76Swtjz4ZB3VGNM8eULB+5Vcgiatkvwuc6xUhDcvyo8yHDCAAAAxKarbeFWEK+TWAwssAnNOMowHEULbU3v+yNf1AxyfIevQYPj7/Zytj+/vspg9cFdXbVnxsvM5ePoAdlFm31cN9eOwMneBFkXapMKMgzpsO8ykADR7YYz4/7eqBZOQp+uvrmxWGTGC2ZUxi8YSCV23G4WqYpu4KyBr4fNY9HqMM5coiP+E+yT/p1WCY3I7KX/4nriTiG8jIB6mKn2Xz0 R41656YN C7CNToZ2Jx+zh/WKDXv++WyOUAeE6GK3btg5K33Sp0iN42b9kePipjclDIMO+yLsPVJGQmwAkZqhsPeVFzdum/9EkoBMzhVWlU+0r7gEYfQd5+H/MTMtVfk2pSHHYptQqDRj1PdpEaIQUHWHOGYF2TqTWF58rW9Wi4XobEDPKX/VgjCB4P7V7NfY4eTxf0Wy9f44HeIg/cveztUtUe5BW3X6znzx120OyvRSpAKNd8Nj0+qxnfdUseyIbCGvP2jLoqu02ed+a0ZxMryAw5W0GZU/21Gtwln045GovbBJmAvXEE2wjg/BtjBAPs1sBQrqee7THifpQcdH7xiK9lVzac50sE1PgD8TamUnWi/fYun4B7RE= 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: List-Subscribe: List-Unsubscribe: On Wed 30-04-25 14:53:50, Roman Gushchin wrote: > On Wed, Apr 30, 2025 at 09:27:39AM +0200, Michal Hocko wrote: > > On Tue 29-04-25 21:31:35, Roman Gushchin wrote: > > > On Tue, Apr 29, 2025 at 01:46:07PM +0200, Michal Hocko wrote: > > > > On Mon 28-04-25 03:36:15, Roman Gushchin wrote: > > > > > Introduce bpf_out_of_memory() bpf kfunc, which allows to declare > > > > > an out of memory events and trigger the corresponding kernel OOM > > > > > handling mechanism. > > > > > > > > > > It takes a trusted memcg pointer (or NULL for system-wide OOMs) > > > > > as an argument, as well as the page order. > > > > > > > > > > Only one OOM can be declared and handled in the system at once, > > > > > so if the function is called in parallel to another OOM handling, > > > > > it bails out with -EBUSY. > > > > > > > > This makes sense for the global OOM handler because concurrent handlers > > > > are cooperative. But is this really correct for memcg ooms which could > > > > happen for different hierarchies? Currently we do block on oom_lock in > > > > that case to make sure one oom doesn't starve others. Do we want the > > > > same behavior for custom OOM handlers? > > > > > > It's a good point and I had similar thoughts when I was working on it. > > > But I think it's orthogonal to the customization of the oom handling. > > > Even for the existing oom killer it makes no sense to serialize memcg ooms > > > in independent memcg subtrees. But I'm worried about the dmesg reporting, > > > it can become really messy for 2+ concurrent OOMs. > > > > > > Also, some memory can be shared, so one OOM can eliminate a need for another > > > OOM, even if they look independent. > > > > > > So my conclusion here is to leave things as they are until we'll get signs > > > of real world problems with the (lack of) concurrency between ooms. > > > > How do we learn about that happening though? I do not think we have any > > counters to watch to suspect that some oom handlers cannot run. > > The bpf program which declares an OOM can handle this: e.g. retry, wait > and retry, etc. We can also try to mimick the existing behavior and wait > on oom_lock (potentially splitting it into multiple locks to support > concurrent ooms in various memcgs). Do you think it's preferable? Yes, I would just provide different callbacks for global and memcg ooms and do the blockin for the latter. It will be consistent with the in kernel implementation (therefore less surprising behavior). -- Michal Hocko SUSE Labs