Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination

From: Chris Down <chris@chrisdown.name>
To: Vlastimil Babka <vbabka@suse.cz>
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
	Muchun Song <songmuchun@bytedance.com>,
	Michal Hocko <mhocko@kernel.org>,
	Matthew Wilcox <willy@infradead.org>,
	Chunxin Zang <zangchunxin@bytedance.com>
Subject: Re: [PATCH] mm, vmscan: guarantee drop_slab_node() termination
Date: Wed, 18 Aug 2021 22:48:52 +0100	[thread overview]
Message-ID: <YR2ARISBFq8O6tSN@chrisdown.name> (raw)
In-Reply-To: <20210818152239.25502-1-vbabka@suse.cz>

Vlastimil Babka writes:
>@@ -948,7 +949,7 @@ void drop_slab_node(int nid)
> 		do {
> 			freed += shrink_slab(GFP_KERNEL, nid, memcg, 0);
> 		} while ((memcg = mem_cgroup_iter(NULL, memcg, NULL)) != NULL);
>-	} while (freed > 10);
>+	} while ((freed >> shift++) > 0);

I think this is a good idea, thanks for bringing it up :-)

I'm not sure about the bitshift idea, though. It certainly makes sure that even 
large, continuous periods of reclaim eventually terminates, but I find it hard 
to reason about -- for example, if there's a lot of parallel activity, that 
might result in 10 constantly reintroduced pages, or 1000 pages, and it's not 
immediately obvious that we should treat those differently.

What about using MAX_RECLAIM_RETRIES? There's already precedent for using it in 
non-OOM scenarios, like mem_cgroup_handle_over_high.