From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E71BE3358CD for ; Wed, 28 Jan 2026 08:06:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769587579; cv=none; b=md8npA5OV+d2GTJAP88R8Bgsyviil90i/Qe/mmhDVrI6qU8ZmAhKlHAsWpFvQyosV43B9ex4xSYTg86d+LoJPf6ALGmrfAy05//luVzpayFuhv65xh/pAoNQzoxU0Ile5lrSbr00jhlqFlIETaXR6eCTYTTm/h87CP1YdeOA+3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769587579; c=relaxed/simple; bh=SO1TGZ8xW8231LsE450thXtlIuI21DNJjXgehoRLYWg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=denL8go6wC3K8TUJ8YtMoyEnddVaPZxO1Lq8QPJDMYu4VVWWqPCjpf/56FLEPkDk6PWb3h79D0+140kf/N59nUL9xVVc1T077wMjANG2x33smF6COFsZjFJh7qLKtKq+nIRsPLRq498d1Hk3I9CsLxX00p57SBa7482DATnl2Ck= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=O2ENoo8/; arc=none smtp.client-ip=209.85.221.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="O2ENoo8/" Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-43246af170aso397488f8f.0 for ; Wed, 28 Jan 2026 00:06:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1769587576; x=1770192376; darn=vger.kernel.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=enqYBRxEAs7b1XTfNQDYASta7yWhNLiXox4ui9P9FD4=; b=O2ENoo8/bEW8gcdI/dgvzkXUDm8xvSOnIlc/ZfpX7PaEAQXJMv9Q6nF+MVYRvzADqq LNNQSt2jNx7QvqlQxRQuzG0LvLD6ENqrTyUUXRyo1/v/uLrQ6I/7O45mb6BV+G+U+Ocu Ix5dTtHtPuxGZT1xi+3r4gWZ0j3y8eIFZB27FVcT/Lr06y1ba7uFzyjcXDIjcmZKZSt4 aBLxtAqNTgiwU1DE33LS4ksm/vyIvRIHitpD9hzbD13L+xp8kD2n3ckRYTw3ivz4g0cP OTYDOO3wYQSHYaUqcss5P0ggpPsqLYWBYWu3huTWdR0zmDY6G5mM/C+yc0/wTztVnMux 6K+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769587576; x=1770192376; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=enqYBRxEAs7b1XTfNQDYASta7yWhNLiXox4ui9P9FD4=; b=VJ4X3sSiQQiq108RGc4uEpvUycEl7IiCp6Im+HXVh58ZIBdB/QE9CKvd/aKxz00psa Wp+cLpyXSJURT3lxiJzMdiePhc1zl9enIlcp4SsbVAuBogd0wv4HXnZiFzNW8Of0AH2n BTkH3F35ldBfmrQ0l9Os7qvYRSTmgvwQZWGKGl/w1Ye0lBCUsLOwV/JoAsVRCS6YyNZs 00NqchVwILPhWafqQQ/0FZ2/TKilOccjMDNI98GlNvTIzL36hk71w7we8Iqe3ug3sxfd JlVKQRPpBu379ySiG/QtkN6JDl9cVydZAGlLNohrDFT+pKCi6qVjIjWC98dUQeVX/9um nErg== X-Forwarded-Encrypted: i=1; AJvYcCU58rnGv3teJkgUpY9KiqmYXGc2dtc4Ndf/+1/Ua0R+UI+nahid/j4ygs97PxN2pQdU+3vJdDLYpKewdyA=@vger.kernel.org X-Gm-Message-State: AOJu0YxYraB/Ixj8POu7Gg5omkPCH4gzHDMiJc/7iyTxYWolvwZvgI07 UglvqVN3zsLDW5SgFxX1wRllbC6fH5k8ZFoWTMvpb8/bUHY2DbChsbeogVwklqclSE8= X-Gm-Gg: AZuq6aL22KI+/aae4rgus9SilJr2ANCLl+dZgLZWcm3xdjxlheJfoe4w6EyYs7+bhSG ZCbd+leTgf29UbMlAdPeQpD240uCyvWvgDnz3xXXjLbdPb1y8M8yaEmNN73YhdmPyoZaRFlraJR 5Rahdj11qC0DCZMUYQ4NGiYeoyKvI2/fsthXfzI2xgh/Ih699fauL7k7gYfdoz1/fAd2EDxMrbZ GtB7jHK3ZvR9M/R/R+AfuP4a/IrStmnq7rDbXoRRr+fJ3cQt5LV55yHWDeFQYDuxtofrdodaimM gzcQDmby9xAcStJtZIhzcKyIfeiqoIB/SL6QpqukDtifCkaAYpgtYVOxgI6BGySWWRdRKlfv4WV MdEcuh0p7wkJvZxFPMRqWf0dRcAyirCson5gm6rhWJtTHZ+gct0SOQAKxqCtK4BKoYtbtCOI5lc ujxIqu2L5XukKOqPTLDQXQH5BJ X-Received: by 2002:a05:6000:1787:b0:435:9a18:5a29 with SMTP id ffacd0b85a97d-435dd1ba13fmr6723122f8f.11.1769587576172; Wed, 28 Jan 2026 00:06:16 -0800 (PST) Received: from localhost (109-81-26-156.rct.o2.cz. [109.81.26.156]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-435e10edfe7sm4930747f8f.14.2026.01.28.00.06.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jan 2026 00:06:15 -0800 (PST) Date: Wed, 28 Jan 2026 09:06:14 +0100 From: Michal Hocko To: Roman Gushchin Cc: bpf@vger.kernel.org, Alexei Starovoitov , Matt Bobrowski , Shakeel Butt , JP Kobryn , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Suren Baghdasaryan , Johannes Weiner , Andrew Morton Subject: Re: [PATCH bpf-next v3 00/17] mm: BPF OOM Message-ID: References: <20260127024421.494929-1-roman.gushchin@linux.dev> <7ia44io6kbwj.fsf@castle.c.googlers.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ia44io6kbwj.fsf@castle.c.googlers.com> On Tue 27-01-26 21:01:48, Roman Gushchin wrote: > Michal Hocko writes: > > > On Mon 26-01-26 18:44:03, Roman Gushchin wrote: > >> This patchset adds an ability to customize the out of memory > >> handling using bpf. > >> > >> It focuses on two parts: > >> 1) OOM handling policy, > >> 2) PSI-based OOM invocation. > >> > >> The idea to use bpf for customizing the OOM handling is not new, but > >> unlike the previous proposal [1], which augmented the existing task > >> ranking policy, this one tries to be as generic as possible and > >> leverage the full power of the modern bpf. > >> > >> It provides a generic interface which is called before the existing OOM > >> killer code and allows implementing any policy, e.g. picking a victim > >> task or memory cgroup or potentially even releasing memory in other > >> ways, e.g. deleting tmpfs files (the last one might require some > >> additional but relatively simple changes). > > > > Are you planning to write any highlevel documentation on how to use the > > existing infrastructure to implement proper/correct OOM handlers with > > these generic interfaces? > > What do you expect from such a document, can you, please, elaborate? Sure. Essentially an expected structure of the handler. What is the API it can use, what is has to do and what it must not do. Essentially a single place you can read and get enough information to start developing your oom handler. > I'm asking because the main promise of bpf is to provide some sort > of a safe playground, so anyone can experiment with writing their > bpf implementations (like sched_ext schedulers or bpf oom policies) > with minimum risk. Yes, it might work sub-optimally and kill too many > tasks, but it won't crash or deadlock the system. > So in way I don't want to prescribe the "right way" of writing > oom handler, but it totally makes sense to provide an example. > > As of now the best way to get an example of a bpf handler is to look > into the commit "[PATCH bpf-next v3 12/17] bpf: selftests: BPF OOM > struct ops test". Examples are really great but having a central place to document available API is much more helpful IMHO. The generally scattered nature of BPF hooks makes it really hard to even know what is available to oom handlers to use. > Another viable idea (also suggested by Andrew Morton) is to develop > a production ready memcg-aware OOM killer in BPF, put the source code > into the kernel tree and make it loadable by default (obviously under a > config option). Myself or one of my colleagues will try to explore it a > bit later: the tricky part is this by-default loading because there are > no existing precedents. It certainly makes sense to have trusted implementation of a commonly requested oom policy that we couldn't implement due to specific nature that doesn't really apply to many users. And have that in the tree. I am not thrilled about auto-loading because this could be easily done by a simple tooling. -- Michal Hocko SUSE Labs