From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f53.google.com (mail-wm1-f53.google.com [209.85.128.53]) (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 681C43115BC for ; Wed, 15 Apr 2026 09:11:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776244277; cv=none; b=FkW51LtclXu/Y7Ckf4Ox7n3TzB/1Y2WtCaKzgjcOBhkJpgjJksCChxiPX2ZOmsf9+DLuXYBW4AEP8C3wGcIN7cHGfB5gRF3hua6hjvKJ7MjYqW/znd01zR5C8O7W0YbaGstWTGv9XPosP8R9C+v4bhjUfik5fd8ISvOdnU8gmpY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776244277; c=relaxed/simple; bh=imlDBneRXzXBS3mBkQLWHFoI6rVyzXU+XdbgxAUAuJ4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=guAawox+OOv7JfgGqTHqu4Y0fUMPAMW0cDeHcfoCYWakZLrBYoYWFrio9QRI3Eps6dJw3eDZFaJc1mVM94DUysMHN5uRDyFhfAEoiigJCN7jwkBCwcIG46JmsFZNA71gov6vpPdqWj2xiKWPlJh0axYxMPYHK5/rzqajS+z8bLM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com; spf=none smtp.mailfrom=readmodwrite.com; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b=LM3UOh/O; arc=none smtp.client-ip=209.85.128.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=readmodwrite.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=readmodwrite-com.20251104.gappssmtp.com header.i=@readmodwrite-com.20251104.gappssmtp.com header.b="LM3UOh/O" Received: by mail-wm1-f53.google.com with SMTP id 5b1f17b1804b1-4888375f735so64461095e9.3 for ; Wed, 15 Apr 2026 02:11:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=readmodwrite-com.20251104.gappssmtp.com; s=20251104; t=1776244275; x=1776849075; 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=niwzD+HTaVSeyOYRpZrIOJZYYAYWhLi1x8LzB4xVLGE=; b=LM3UOh/OsXeKDBLCuOHde9OxnF+MR5qsycMpR91ffNz57brtxaEDOg5eDfvUWgsBdh uMVr9PMS1WGy8IEGGT4mGcQYodm+GWgGBffnNrokXpv2+3QR3VsMZBXYrzjWwbN7xZ/F akHzWULOMQCc2CvTM0kKtI2vLqDxwvH5GSfWcM7DS3CCYXYKPflAJaID65vdBxQU68D/ 8LyjwgOtvGvM02uqa23nAdgWAzAz+90FH8IVB/qJez3BD7ih/BtqJ3h9YeHI4NwtVGl7 OI1DyNIun3zHSPd0HeIzyCR2F9Goauc1n7usmI4bv284URLwAe5kAXTPFVmDnyfjuD1n T1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776244275; x=1776849075; 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=niwzD+HTaVSeyOYRpZrIOJZYYAYWhLi1x8LzB4xVLGE=; b=PZC4ORst0w2KNOxOg2QcrSY0VzrHF8NR3+5RHFLZuo3vTXwUpJVpGonanxLOCB167/ ++wCQ+P3BI7hcPi/scJI0EPZ3MX0KvKniRKs7SCoKvRWWWtcxKPZ1XecrSacenrhOAN1 8yZ5L2u0M7SC9FQ/y3oL2zyHx5VKazMedOzUT2WKS21gYxpGOaBDkmzWMjNCm+Zc7Rb2 U2+LgxJVeWLEyKrxInbTkmSNJ0VpavLNjzAJGZbZbybW+83jYkT7M+lEDB9nHrsCbRBJ gqm8jjTkLo72zmU5JUGP7XHhWxe+g76toaFyk2UmqU7OuDSntA2hnU8nnXzXWuNCH95Q S1/w== X-Forwarded-Encrypted: i=1; AFNElJ8eNgNzNU6MXC99GUsovMWsul2q5TjdCZ3fiA8oEslR/ZDv5f+2rSXMTLEcHgP5gEcEbZ+5pPTgFAk2m/8=@vger.kernel.org X-Gm-Message-State: AOJu0Yx87ZxjHqDMwutYlSUdGjwwaxCxvcQowTzKrRxYM95lfCXGHPB9 gssge7hmyCdHx9nCTkZ8tIffP5gfjyDNRgLkpbl8jD627sZUYGNqfZsvJ/xF/ycr4oE= X-Gm-Gg: AeBDiesuFWI7liuOiHozxM8R5U5vyNbj/jSsuUZ6gzquV1UCK4+LPnJ+Nc95rWzEJ7V jzcg2LA4iiROFfQwNEr6xbbPPpw/82qVb++tVZBP147uYfjUsJxSW1U8BVQyY/p7t1XaHvkQuc0 aPbF9Vk8Ri5FtTfs+njMy7wt+X5r8tBaDg77awvJt/iTaOGOXR3MrJVoJyA+4NOybR7+arpWVJF TOW8CRpDyKBJTM0hm3YR3K+c9VC6qZ1A7VEVvCsn852CvJcLemhP2PWDKjT/CPnM2OSN2b96agr xp5aGbxhu+O0vYz+CVBpJe0C2zd/zLJiCxoPzVB5GVtQwxLauvKexS0BHwLkZDGhh4KUr9V9Z2v htz6cnln38cSFELH8yB8NWdLwirCvznx0xiXLandjxKJnb4xzHffLgfmDroIIUitCswbrIwFPu6 fyw3qiyWE1wAzPSYl9lbUOuwOwTdo2Zfw= X-Received: by 2002:a05:600c:8b6b:b0:488:be21:54b9 with SMTP id 5b1f17b1804b1-488d67ce792mr300007505e9.8.1776244274651; Wed, 15 Apr 2026 02:11:14 -0700 (PDT) Received: from localhost ([2a09:bac6:37a8:ec8::179:23a]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-488f1d60ec2sm35799535e9.0.2026.04.15.02.11.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2026 02:11:13 -0700 (PDT) Date: Wed, 15 Apr 2026 10:11:12 +0100 From: Matt Fleming To: "Vlastimil Babka (SUSE)" Cc: Andrew Morton , Christoph Hellwig , Jens Axboe , Sergey Senozhatsky , Roman Gushchin , Minchan Kim , kernel-team@cloudflare.com, Matt Fleming , Johannes Weiner , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , Barry Song , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Zi Yan , Axel Rasmussen , Yuanchu Xie , Wei Xu , David Hildenbrand , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim Message-ID: References: <20260410101550.2930139-1-matt@readmodwrite.com> <6ca33173-145b-43aa-8a8a-34985d375246@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=us-ascii Content-Disposition: inline In-Reply-To: <6ca33173-145b-43aa-8a8a-34985d375246@kernel.org> On Mon, Apr 13, 2026 at 05:38:19PM +0200, Vlastimil Babka (SUSE) wrote: > > Hi Matt, > > so have you tested it for your usecase with zram and have any observations > how it helped, what values did you set etc? Hey Vlastimil, Yeah I've tested this out. So far, results have been positive -- I see system-wide OOM kills when memory is low and direct reclaim occurs, but not so many OOM kills that the SRE folks have started screaming at me. I've only run with the proposed 1% value so far. I also ran a bunch of benchmarks alongside a memory hogging app that peridoically touches anoymous memory. Workload rpp=0 rpp=1 Notes ---------------------------------------------------------------------------------------------- Kernel compile + anon hog Completed, no OOM Completed, Global OOM confirmed from Global OOM fired __alloc_pages_slowpath Memcached + anon hog 282k / 2.30M ops/s 562k / 3.53M ops/s Global OOM killed hog, No OOM Global OOM fired then benchmark ran faster Pure fio (5 reruns each) median 3710 MiB/s median 3702 MiB/s No reproducible regression Mixed fio + anon hog 2747 MiB/s 2915 MiB/s Global OOM killed unrelated services reclaim_progress_pct=1 seems to help in these memory exhausted situations, and doesn't appear to cause a regression for the pure file workload case. If you have any suggestions for other tests or benchmarks to run I'd be happy to do that. Thanks, Matt