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 7F655C369DC for ; Wed, 30 Apr 2025 07:27:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FCCF6B00CD; Wed, 30 Apr 2025 03:27:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D4826B00CE; Wed, 30 Apr 2025 03:27:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 399D06B00D1; Wed, 30 Apr 2025 03:27:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0FF266B00CD for ; Wed, 30 Apr 2025 03:27:43 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D1DDB80934 for ; Wed, 30 Apr 2025 07:27:43 +0000 (UTC) X-FDA: 83389880406.15.7327866 Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf29.hostedemail.com (Postfix) with ESMTP id B29F8120007 for ; Wed, 30 Apr 2025 07:27:41 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aXEQ81FC; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.hostedemail.com: domain of mhocko@suse.com designates 209.85.208.54 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1745998062; a=rsa-sha256; cv=none; b=JzU+XeQl1BNFGn1CBxfNDCYTJISBOPe4T2mafh5GixMv5SB7ZtcJ6a7wBBZsM5WZAPSCYI f2iV3Lj02kXAYQnuH5GSwGmrm5dcqbEJBWBJr/P311luoBBJwpM6OqFA4PKRxnXERD3rUc PTx/SPNyRS6p3Op71BoGxMp+ec9E4Sc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=aXEQ81FC; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf29.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=1745998062; 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=TlBz7iF1hek+FTGw3X4aAHw5f1S4jYqTggUPhRMIVXc=; b=iFnxPxMXwblh/gsLJv2eqvAlAE/xG4Z/s+x6NojeRfS3hykDyPxQEs19hoksHESaIvoXdy p4xE/neeSq1ZXpva+zEfWOB1vXvdOq+kg+5U9T1pgTyk4falMhz6uHbGfUBU/o4Z0bJRBl tFCbUQN02kMhEdPHan8mY3UmpXtF8c8= Received: by mail-ed1-f54.google.com with SMTP id 4fb4d7f45d1cf-5f6fb95f431so1232276a12.0 for ; Wed, 30 Apr 2025 00:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1745998060; x=1746602860; 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=TlBz7iF1hek+FTGw3X4aAHw5f1S4jYqTggUPhRMIVXc=; b=aXEQ81FCFbCArOIVwCbLw2MIl2izZgPakRoyoS0yPgwq2yHNC4jRCGokAVqcbxzHEJ y10cgUfbnJakvDSV2gNnRU5m62DYjIgcRnlyhHLujVDI6Eboe6L6JNHzEMhWRxF0Medt y+/sJLPRP9I13e/Vm7CeCrnezWXWjrSfsEsmVILgwZb8dfAed6ZEeiCfLpWZg68MMGvR kWy8xlD1B4UjS0HmAn74u2bBaiGpt7hxpPf/c6mUyWIgO4Q8lwBzTAtknmIfw6MESej3 9aNRJzzuq25Pih404xdybbnaSQNhHZeoqbBMQd/kQkKTk3El6OXdvl8MT+VTL3DrKXpV iKlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745998060; x=1746602860; 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=TlBz7iF1hek+FTGw3X4aAHw5f1S4jYqTggUPhRMIVXc=; b=PV5lJDMrvQf8DOUBhUG/HecGUseh9cQ98AO/+8Pklcq364Es4fhv0bcLAuAc9ambKp GL7B7CzhbJdC1A+z5kTnG8WhnN7ALrMUeWVq2e4WAo99ZYpYoPD2IMZFFS7FdnBI07wS +U+egHVev5qnX20z5sy3jazPXFNfLtEy9DzSjx0SG/IYFfEFAMe0ix/JakUyhmteMkAp Q/D3wUNr10bCuG0eVmGykwOWP9LO5v3uv5aBSYbcrOM+kgpZIXpuoSCUol8vpF+wu1jk kPZ4zUM1Ymvs8ngjvNdF0O9Hai6giw0RxBiSAXuzHg4Wl1RND1TvipfIim5TQhuy0WU1 fREg== X-Forwarded-Encrypted: i=1; AJvYcCVMy7flcv/WVvHCyaZ0IVv+/7Z0tdBe7HeWmgbbqAD060Y+Q6Vp1A70WE2Y2c3s4GJ7rtXtP3L0Gw==@kvack.org X-Gm-Message-State: AOJu0YxsNRk6GsvwC7hmICfu8C1QC5iah1Tq4Y4NQHnvEXbelOA58sq2 onMjzgGzAip/46cexmO8J44H90PbruVyZJIwUGSllKqPk+Qq0IQEZ5IeOc3xCRc= X-Gm-Gg: ASbGnctsafkHYn6q41fPtcCaUf26goDrHprPGHBhfpyP0pkPiJ99GXUlAL5AY1WygST nKbwjvg3xgOrXkAnvKughHgBOvORuBFSJeynh5/4OhH3q0m0BPUJnUgf7MwQuMwIjdeDxKdPPXh fEvLpGucCqZCxEaY8hNPkfQzL0nBESqfn4sZLMANfagpL+Yvin1I4tXIW5Z9+1Oc9vliwJbsCa/ hUCxb2FS9QW/uTcVOsPQXx63bGHpf9szhm1v+LEEWPk4/toQAkvtNbefoRcMB1vDz3n+WrfNylL Zikh5UZxH5BVS4kTf0EpOaFsf7c8/cI= X-Google-Smtp-Source: AGHT+IGHXR5iYRXyJph1iKrCVhcSCgbOSnDW32/4au9VmEwpUAXHvuV7+98LviohpFzXoUW7wi3S0Q== X-Received: by 2002:a17:907:f495:b0:ace:4ed9:a8c3 with SMTP id a640c23a62f3a-acedf68c196mr173112266b.7.1745998060149; Wed, 30 Apr 2025 00:27:40 -0700 (PDT) Received: from localhost ([193.86.92.181]) by smtp.gmail.com with UTF8SMTPSA id a640c23a62f3a-ace6ed6affesm884107766b.130.2025.04.30.00.27.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 30 Apr 2025 00:27:39 -0700 (PDT) Date: Wed, 30 Apr 2025 09:27:39 +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-Rspam-User: X-Rspamd-Queue-Id: B29F8120007 X-Rspamd-Server: rspam04 X-Stat-Signature: bsdj9dm5iactawyi565bift94x944oc9 X-HE-Tag: 1745998061-470965 X-HE-Meta: U2FsdGVkX1/13dpuOyrvy6i7ap8bOnHPoTp62X0OXz3/FafZQLAqMaVX352bV1ZK+prNjjLUTNE9sfrBz/ssZm7auAaQEUDatKkFXIRRdFSiKSe31hzhX9NtjtCSV1x+k1QKQlt4NrENT6U/43cuZs2lFOC1I5zL/GA0A0jDomZZTUZkxHJOhBfeStCAKICKbFpDZIcmVyliNmAQNM12s8cbL4XNJTtRNIjCBTRF6/gdmY5qo0Abtq6AMXDlmqqe6yy+vCj4AA8bycxW7UeltALLB6nTcsBKxCK12WostZRb3DEsUkoybZJUJn0H5znJHLw96DgiQgmgpKIMNu3w3m5o+JGPocxGhY5JIq/XmeOQFm2Hdxw7rKHaJ5MizKbQxu5w10cGC5PuU+4R6DAEWe2nb/XrDR8GBWlwMh6juV5rtf9Pcrf3xVFahQIPtdW+LhjvOemjboh4CweqOaCXE+W3NTq9KHQhv2D3iY43Bwyr4vR1LXJ2NCJuMKv6MghyRUT2CHDOvFVFVQTTUIXp9gPJ4SkUYTPV6RtHs+zkTOuYbFmrGqdla144cmerBz/kSrYEVpswhL0ujXAchmX25MogsWNCguCHOvUfECR891y/7R/BwpSJUSREYkE64RmDz0zKjpI0NhtT8TM+/z8d2UNvd0Z7qSFu3jlTeFC1kcYbKi8wdIdKnAajVH7jgVEepdJEMc5QeS5T7n8igoWxnoEwGnFbQlLpXEBsbcJUINBu6deRnrsZGx7TDw0PrqHYGRuuOKK7JgY/51ScjUgDjkkZ3nITTBHyiL/XsD67p60TYoyy7rm1dFZ6PXbTyaFAkOoxfpJfRm7WPCN/D3h5zTDiGDIFGNRAZI49OGMoL2Q6AaQtdzEmLOPVfXIoBA0R65m22vyuIaStJXYDaCM3aUfDede7epmos7CUAisYoTWte2RqH1lgaakp5hjKj0FnIbO380q4r8AzhvlDF4X IMYzLJBV Uh2SoyDRAP8PZTuwMotOI0Qorf3vMNGwL69m9v/14jeXN3MQNdwpudmmmZMCKmkMjLkiwpH2vZU+hpx69Llz4ZpTXhjYPvTk7vxnuFxpC9XjTkeowPlBEEi1GD/CVjamM40wqlJTBSw+8Lud0ip9VzqCRrRS0ICQjELJRv/h6tDUAEgOc3xiDIS5sC2U5MYaMlr/XJNkztbDGo40lhvC/eMG9ieWQwhOCKHiAbffTZXxkgs61yWxXz2Bje0VH4NSfgDG9H++atgwUIBF87C+aSJas4YAhyHDG8hOO4qvPMwnC9F4G6F5GoY+xEMx5FA1+m/nBbGQjKAgyYLUAsrax2CLV3cFqo4dpHe8YLKxXXhsZvLU= 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 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. -- Michal Hocko SUSE Labs