From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (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 DBC6C33A031 for ; Fri, 24 Apr 2026 07:40:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.51 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777016422; cv=none; b=P1lABNe9NBEcXsKWRJUcPMjf9xta/5UfMr9KRanCe8BMFiy7q+C2XjcYEb1Wp3fptWoYoy1jxkNujbV+pn7B8+6awKtHfX8jkeMBFgoBLXTR8bg0Y9IhumGviyrm3E9/LLsyKtJuuH4S6B84GIW+QvBBaINmD1piVoV1+RNyDRk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777016422; c=relaxed/simple; bh=b5oINnrWB0sSuRBHz16m5uovZa0EsOv3IETsNnHairI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=uIKSRZXsNRn+t/URPRTI3I3FJr60Q0vxymwjkfr/wyMdtafmJj3Z5Veo3WIu1FfGuWy/pJtM8fRkQHT7nqu7Qo2hOwFsrGMxIK1pRpD6IKoRW9+HVqkbtEoquWTFuKNfzqesj75xH6+AF6DzCO3k6iX0H4wyO3r+fPgOHg2PREg= 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=NsCwr7oy; arc=none smtp.client-ip=209.85.221.51 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="NsCwr7oy" Received: by mail-wr1-f51.google.com with SMTP id ffacd0b85a97d-43d734223e4so5151271f8f.0 for ; Fri, 24 Apr 2026 00:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1777016418; x=1777621218; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=m0VAcz4ATYMH/1d/fpzj1hGVPWyeDCA2hnjINcATRss=; b=NsCwr7oyxJG3gRszNcVj/KbO8zLWpmf9PJ3koFfwv41CCteHHD+8LgqmczQDkmF0Nb 2AXLuxr6ru43UYFLKDs86uPQK0r4IZJqPButgTAm1Bn4o+LoVsO4/Odrq+7n1i03nNrH BCKxmtJgb3kCmqDwbCDZKt3lG+PzcbLlqEc/lI2ZXBjewGVelbNEmyqouNBmlEhoCTtR PNO51kE2PMBPIe2Pv5p3b+cE0546ldkATzrSPQfJbSb5tQA6o4CCVXjfckew1t8jMLX7 Wrkd6RTUgWi4OYk4aTK4WIvQR29XQ1LWzh+WYLXMQYnUqE61so4vg0e+adcwVjEqhUkk C0HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1777016418; x=1777621218; h=in-reply-to:content-transfer-encoding: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=m0VAcz4ATYMH/1d/fpzj1hGVPWyeDCA2hnjINcATRss=; b=EsV8NCe5bOVmbLSZMPAuGnTQR7kXxPipb22AWyjahGWv1TrCk0ioS06unSPKg2duKM 6skQAWz81B+v0U5mjr/CWcrv6oVNn95aAg7/k9XyD4Xj93OKPKXoZ/wZnTY/8kxua4eg us/5EQLkfaV2FmToe4cSZ2WBiZTRIThugwBk2/lziv5QWZB/dDN7NAkdVOartnoAPPzs h/um8bY4/esp61Oc9LX9/a4AaY4eFKL+x32Joy5BnLFZxyL2/dvVagM8ylADkpfds4NT K3+xjJRRo9R5J4bM5DuYFvFA9A2ShcGmmAGWOckS3XVrV71OZlKezTvpI2yT96kSrP9S Wr1A== X-Forwarded-Encrypted: i=1; AFNElJ/DRAv776hl9RbbJpjPy6E8BhZ/vJRu+0/1rPNUscCDVdIDcEZjVVNiYRwPUcZuv9W/jzSNzXTFg3ItYzc=@vger.kernel.org X-Gm-Message-State: AOJu0YyNdXGK43Yw3R992owxTuVs+dLjH7DowBN+UunLGFTwVuWVvu3/ OQ7dcLN8sTxsEbCGmT1Il3UowCFPheMvnB8BvIdJj8ihG8hRGaMKjzaU2FdYBaZnaO4= X-Gm-Gg: AeBDiet6dhZdjjJ64oGEPGj9A5V6lH194BRsyHNuZ6HJQGCCHUc0jIposAkztKwCCbA +hMnCeemr7XKaUc14sqxqmYWCmmEConcGTX3PDBhRl+xE6PQZiw3+9OxixQ2fXVVPOKPNGenO6e kKC0gIlV+hmPO32V+WcDYzd4a7glQVTvcafqqbc6Rw+mcbv4g4BMu+RAcvIHMAJrisZjqkTPg5R 5rg9/aCMbIlLFSyCq8qE0GRxltqrWpsXWoqA4f746ntA7fG83OL014DnM1Giv09SPcd9eFnwEBW JW+i0Nbn1zO3hubWSPlEDHDCfJ0TzP8aIKBy25USwkH1vVL8ahgzHpviCu0zkcIxsNbfJSt6u0z IUuZxohwqN2hu4mHGs2TQg/XkPvrnU6KHOYjNBKbcLLaIODx2CQUUwcMACYUgLrYBUAAKzzdnr4 QO7Zy5127taRIabgwRy9VGVm+/geAYwUkibg58ecaakQN5J5c= X-Received: by 2002:a05:6000:1866:b0:43c:f257:c706 with SMTP id ffacd0b85a97d-43fe4088c1cmr47698438f8f.23.1777016418081; Fri, 24 Apr 2026 00:40:18 -0700 (PDT) Received: from localhost (109-81-17-171.rct.o2.cz. [109.81.17.171]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4411c9f4f03sm28444007f8f.1.2026.04.24.00.40.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2026 00:40:17 -0700 (PDT) Date: Fri, 24 Apr 2026 09:40:16 +0200 From: Michal Hocko To: Suren Baghdasaryan Cc: "David Hildenbrand (Arm)" , Minchan Kim , akpm@linux-foundation.org, brauner@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, timmurray@google.com, Johannes Weiner Subject: Re: [RFC 0/3] mm: process_mrelease: expedited reclaim and auto-kill support Message-ID: References: <28c3ae9f-c974-454c-b8ed-ba0ba0a5706d@kernel.org> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu 23-04-26 15:36:57, Suren Baghdasaryan wrote: > On Thu, Apr 23, 2026 at 2:50 AM David Hildenbrand (Arm) > wrote: > > > > On 4/23/26 09:50, Michal Hocko wrote: > > > On Mon 20-04-26 14:53:23, Minchan Kim wrote: > > >> On Fri, Apr 17, 2026 at 09:11:21AM +0200, Michal Hocko wrote: > > > [...] > > >>> Yes. All which make sense, really. I am still not convinced about the > > >>> clean page cache because that just seems like a hack to workaround wrong > > >>> userspace oom heuristics. > > >> > > >> I see it a bit differently. When paltform decides to kill a process > > >> to free up memory, they want that memory back right away. > > >> > > >> So it doesn't make much sense for the kernel to ignore that and leave the clean > > >> file pages to be picked up slowly by kswapd later. > > >> > > >> In some aspects, you can think of LMKD as a more specialized, userspace version > > >> of kswapd. It has high-level knowledge of process priorities and knows exactly > > >> which process is safe to kill to get memory instantly. The kernel's kswapd, > > >> however, operates globally without this specific process-level awareness, which > > >> makes it less suited for this kind of targeted reclamation. > > >> > > >> If we force LMKD to rely on the slower global kswapd to actually free the clean > > >> pages, it defeats the whole purpose of targeting a specific process. > > >> > > >> So letting process_mrelease speed this up isn't a hack at all. It's just helping > > >> the kernel do what the admin wanted in the first place: fast, targeted memory. > > > > > > This is a very creative/disruptive way to do a memory reclaim. From a > > > user POV I would much rather see clean page cache reclaimed before my > > > apps start to disappear. But this is obviously your call and your users > > > that will care. > > > > > > Anyway, I still maintain my position. I do not think it is a good > > > idea to drop clean page cache as you do not know whether there are other > > > users. > > I'm very much familiar with these issues in Android and really want to > find a good solution for them. IIUC, this RFC tries to address 2 > things at once: > 1. handling clean private page cache when reaping memory of a kill victim; > 2. addressing a race between kill() and process_release() when > process_release() can't happen before the kill() but if it happens too > late after the victim passed its exit_mm() then process_release() > fails to find the mm to reap. This defeats the purpose of > process_release() call because the actual memory (released by > exit_mmap()) might not yet be free and a successful process_release() > would be very beneficial. > > I see these two as separate issues and I'm not sure combining them > into a single discussion is a good idea. Fully agreed! -- Michal Hocko SUSE Labs