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 0E454C369DC for ; Tue, 29 Apr 2025 11:46:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB1686B0007; Tue, 29 Apr 2025 07:46:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5FED6B0008; Tue, 29 Apr 2025 07:46:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A28036B000A; Tue, 29 Apr 2025 07:46:12 -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 83AB76B0007 for ; Tue, 29 Apr 2025 07:46:12 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B74B5160D92 for ; Tue, 29 Apr 2025 11:46:12 +0000 (UTC) X-FDA: 83386902984.16.BEAECA5 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf06.hostedemail.com (Postfix) with ESMTP id A79AC180007 for ; Tue, 29 Apr 2025 11:46:10 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bP19v3p9; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.54 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=1745927170; 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=znQpdTxcq5Q59q25hWrDZ7jqcfAs7XVIcl5H5jOTHxU=; b=QKZZ7UtA8HBhfpOv7dy9Hf1gDu8EPcm/hFoGZz4UhjIted8Rhfwmm0Q5m8Hg9QXCt/Kd08 zGUMclW3KCAYO5mIG8pZ4aBEYRHlI7dLJZT0vioW0zooF1DE5+KjWoPYhwDy6cvNdLG4pT Pwfn9xJYzftYwvfILqr81GgHEt0mt1E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745927170; a=rsa-sha256; cv=none; b=yGL4Yfq/jvIel9ec2S89P2EoGWj4nZaC6MtHqD7Iz/RCXNbkFXj1K05tC6hIejyikHeeT6 CLG+yb3+JM/reF8a1IB8H/9NsQTh2oEWovmBHli1kfWWne2NCfCLg9wGBxDr2Udjvl641G As/X1tRIlVHA+VRESykPzOb0wxHT2G4= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=bP19v3p9; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf06.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mhocko@suse.com Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5f6214f189bso11468266a12.2 for ; Tue, 29 Apr 2025 04:46:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1745927169; x=1746531969; 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=znQpdTxcq5Q59q25hWrDZ7jqcfAs7XVIcl5H5jOTHxU=; b=bP19v3p97/nWBbnZHCTyKpFNGbOZCiRJeqCRgeyscdSH3PZb31HUcloEVMX+3SbxQu Oc39sUbmx856jvAEo1g09X5ICColRZcwrgP5PFIOkbR30tC9MxexmNs7XSKFktN4GMju ag9wQTD0SxpdC7zCmzGrvVvvwabbUPSXZZ+yXmfnIzro2p1dSmXn2oangIjop+BPDrl4 QKKqbB+E1npN0szYREl4r00djQ7R0telT0zV0uZF6lxKROiQe69Zt+BdgDy2cUpe5JlC I+xy/SsQ8DUqLRncXmDyk6Qvx8iYcXRFhMau2PdjIxYtMo5s4q4OJC7dXXtPPn+VgBkV iQFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745927169; x=1746531969; 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=znQpdTxcq5Q59q25hWrDZ7jqcfAs7XVIcl5H5jOTHxU=; b=FvAPVCzlPjyJCFZJPFxaO241wCdcI7iBT3EEhQrkHh/4QgdI8Dv6OgOQIENpcYNwUE CmqwnZMjvVJ7+wfbamN58klYy5SGx7tfXkPw6poeyrVC++UcPp9D9sZvDkxno1IA7P7v t286ori3XgpU8Q9IuwDBNTNJgYvFyIXNzbqWHnExervKFevkRZfUU8sJ65bUc5LE4Ssa H81ejOd5y8LnY4MX4PunZiiXFtx6OESE9jqgZeXOobOGUmXv0H3sLQ+UNzfz9WdhKBzC JS7kz93aKAyleyBlOGWcZZA/xJvem09ls1RTBbe4tJzHHd2qidVKNjqDevQwpA1IzwJO HUvw== X-Forwarded-Encrypted: i=1; AJvYcCXDE8VrE4N6QTpMu6zaLwpE1c0QwI5pNgWqVd5i8fk2AQOyq8AyFWiGNRJgp5H66fF3TLoAUDFP0A==@kvack.org X-Gm-Message-State: AOJu0YyhcQy8Br2khPmO6KUXuJr0cIUgeqY0pUr31Q+tuLIXHN5Xfsiw MsOnGAGC4itbOiW4SSERXp/6Higkd/YzFsk1helan38GKjSmEiP9EgPr4LGqm/4= X-Gm-Gg: ASbGncvsaLCgD/AxKw20Tm2Sp7ZLihWc8S4PKPDWGSQzXCNfGZiV+RHB9FvQW/BB0CT /RD6Xv86HixVEJZNT/XBjUnWPR0dnoVoDe7UveGJv6qp97+R2hltVMUeVPLamSb/pmxHGfWcNZS EBeQqD3ENPOYKM9LRiHQ8C6imEODRDCWaVgmSzKDWDyN76rH8TD/LFU21e0fqztOa+9L1Jhf2mH ExmpwjfJIp7Mu9usiau6MMTFnx2pZzoJkCvpt4ZzFDL8KeagWPY09VoTrjYHkpkDK23pRdxO+LO Y4LI8+ySC5hBJIujuhn3wxOJmd1RhGZi6akbs1yLDdA1Vk25jHWgdQ== X-Google-Smtp-Source: AGHT+IHdwrLpQIpUiiyBR38B/ZttRSS4g/Wv80xkTkGlVkMPcowVbaa+12lFPhCvhIOfAu66scr/kQ== X-Received: by 2002:a17:907:60c9:b0:ac7:cfcc:690d with SMTP id a640c23a62f3a-acec6ab3db1mr282121166b.40.1745927168683; Tue, 29 Apr 2025 04:46:08 -0700 (PDT) Received: from localhost (109-81-85-148.rct.o2.cz. [109.81.85.148]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ace6ecfa33csm760681066b.119.2025.04.29.04.46.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 29 Apr 2025 04:46:08 -0700 (PDT) Date: Tue, 29 Apr 2025 13:46:07 +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: <20250428033617.3797686-11-roman.gushchin@linux.dev> X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: A79AC180007 X-Rspam-User: X-Stat-Signature: 5ibhtjbn87j5kwcbdm7m99bqq8ipbohg X-HE-Tag: 1745927170-706661 X-HE-Meta: U2FsdGVkX1+p2d34PubhmChn9HfRDIfT0YieYDbzFtLRqfd4Ur8G0fGLqiu2VK160aggfZi3l+A9DLNsoBViQAU43jPz4lSzAGzJc9fchxkL6q/30wpGA9rz8nplWyXOjBh7khaaxJRyhl28ocEm/sDnjhuyNnwXpSY/zML7Vy0/A/sm1L3USLKQvzaQTkDmyv8XaSi9iGSBSEVU20NMt2QgoHyl8wom4T6lEBU9i3HXj+ZHBFSBDHcdvKq1RV8ajmi56DTnMPZ0pTqM1vZF7SF5gbV26dYkScfp/jIHrv+H8m2jjRZZDtfk33u6bhMbswBAiVl6sIOLaO/CHQaqkg7xzHvaWOWaXvoFQDEUEctHxnvNiJM1k1SfWt6XKe5AVtpCQDsac3uuqnoPRg7qLODaRtIUiI+ZFJGmEwmElg0FXERdBcCU9Vm9AYkBdb5XTreTYloJWT4j8ihb8+H6NvFNVfEl2zm6BhZJIX06Hlb+YvdETS0C6+QS8AA1+JhiepBwRb/qu2+BbsEZ8taSNVZN8REBrMuxF1/oWIjRV25zd8rJbSKuJj7DiS6YDznidyGRg00mnrUtjOBtdZ1njomWOowdT1TFkgx7HwALVrCSljlc+lJaparVcXw45EHORxNDFOXvUxtsmJyyjOTounfEaWMdxLQw4yPZbUrldXHrFEr96IgqGbyLi+7GJWWVmPq14SAAbALq0CiFUmRc/LkuAk5PT5OLNFJnwOfhNwn+5HQ2x3aZ7vqQKnMnbJl+JwnwiWG3KiEgm/hGPW9BZJWMoZUwgQIC+i6AJs88tHL7qzblqDgJNfeN1A9H41iLG9ebk6WUdh1cATosq9OKEkzgEeVTDKyJ6Nd6g1rJZS/TN/kNvnWerAbQW74KIzDnlzB1tg+dnUbDn4SE432psP1V9H5ICEIv9IhYVus1KNwslSFVnK4D43JfcnG3z/ntKj9tpObASlm8tKrzr7V 7wcBYOGn wrkrkwc4yx+bVVRwPpmSSAY2KqQhD8YFqvZvyCjjR+F5/LDzCt/EqPkEdzkxwGsaRe1j5hqe3QOBWgrys9RL05h1S/01yRA8upuHcS2x1/Za4g0pWgdccPLVP3Gb9Qa6ZLi30yDRoJ3wU6QNu9RlwPkyKWbOYOaX89qj4R4T5yr4BruLaFZVs65reaAq9BxMIi4/zu2z2yeNwh+ZGT222Gs/O7ek966UOZAp9DDsCfxNtJ5yoEoQ9KjM8dlgbocCJSyBPjgtFPivy3OBkP5a6QlnItpY8+C6xZ4mIIwNfSSnzshxKz1ES0Aw6mQw7ATaR45oTbC+mY2rA3HDgzInC4ZSgdNgsNRkMsXOz3hVOsy2j+FM= 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 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? -- Michal Hocko SUSE Labs