Received-SPF: pass (google.com: domain of linux-kernel+bounces-189220-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Fri, 24 May 2024 18:03:58 -0700
From: Roman Gushchin <roman.gushchin@linux.dev>
To: Michal Hocko <mhocko@suse.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <muchun.song@linux.dev>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Matthew Wilcox <willy@infradead.org>, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH rfc 6/9] mm: memcg: move cgroup v1 oom handling code into
 memcontrol-v1.c
Message-ID: <ZlE4_hzesg-d6WNc@P9FQF9L96D>
References: <20240509034138.2207186-1-roman.gushchin@linux.dev>
 <20240509034138.2207186-7-roman.gushchin@linux.dev>
 <Zj4gi-vOxLZi2van@tiehlicka>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Zj4gi-vOxLZi2van@tiehlicka>

On Fri, May 10, 2024 at 03:26:35PM +0200, Michal Hocko wrote:
> On Wed 08-05-24 20:41:35, Roman Gushchin wrote:
> [...]
> > @@ -1747,106 +1623,14 @@ static bool mem_cgroup_oom(struct mem_cgroup *memcg, gfp_t mask, int order)
> >  
> >  	memcg_memory_event(memcg, MEMCG_OOM);
> >  
> > -	/*
> > -	 * We are in the middle of the charge context here, so we
> > -	 * don't want to block when potentially sitting on a callstack
> > -	 * that holds all kinds of filesystem and mm locks.
> > -	 *
> > -	 * cgroup1 allows disabling the OOM killer and waiting for outside
> > -	 * handling until the charge can succeed; remember the context and put
> > -	 * the task to sleep at the end of the page fault when all locks are
> > -	 * released.
> > -	 *
> > -	 * On the other hand, in-kernel OOM killer allows for an async victim
> > -	 * memory reclaim (oom_reaper) and that means that we are not solely
> > -	 * relying on the oom victim to make a forward progress and we can
> > -	 * invoke the oom killer here.
> > -	 *
> > -	 * Please note that mem_cgroup_out_of_memory might fail to find a
> > -	 * victim and then we have to bail out from the charge path.
> > -	 */
> > -	if (READ_ONCE(memcg->oom_kill_disable)) {
> > -		if (current->in_user_fault) {
> > -			css_get(&memcg->css);
> > -			current->memcg_in_oom = memcg;
> > -			current->memcg_oom_gfp_mask = mask;
> > -			current->memcg_oom_order = order;
> > -		}
> > +	if (!mem_cgroup_v1_oom_prepare(memcg, mask, order, &locked))
> >  		return false;
> > -	}
> > -
> > -	mem_cgroup_mark_under_oom(memcg);
> > -
> > -	locked = mem_cgroup_oom_trylock(memcg);
> 
> This really confused me because this looks like the oom locking is
> removed for v2 but this is not the case because
> mem_cgroup_v1_oom_prepare is not really v1 only code - in other words
> this is not going to be just return false for CONFIG_MEMCG_V1=n.
> 
> It makes sense to move the userspace oom handling out to the v1 file. I
> would keep mem_cgroup_mark_under_oom here.

Hm, I don't see any usages of memcg->under_oom outside of v1-specific
context. I probably miss something, can you, please, clarify?

> I am not sure about the oom
> locking thing because I think we can make it v1 only. For v2 I guess we
> can go without this locking as the oom path is already locked and it
> implements overkilling prevention (oom_evaluate_task) as it walks all
> processes in the oom hierarchy.

It's a good point and not obvious if we really need anything of this on v2.
I guess no, but will think a bit more.

Thank you!