From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f45.google.com (mail-yx1-f45.google.com [74.125.224.45]) (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 AB190372B51 for ; Thu, 22 Jan 2026 18:34:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769106903; cv=none; b=cdxZ+YDDArabK/iKrm+BnyCbTu2jfinWq+mbM2Lv/XAA4E2KITPC3tWcoRERwG4zAqTSUJqMnaRW8E1kKexvxY8SEq2zt8Xht4EFRFkyJeBzmHl34mvFLgHqQr2VT1Y1yoB+5JeOoCsMeW0ghqigZAyIqD/yLxGO2Wz4UdZQy6I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769106903; c=relaxed/simple; bh=wbtFg+skcBqgF5MTcXPSDxO9rOPC52NVjval1/lvzxA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=N7j61IzTQyA1vTCOcYeUitj4lzyyYO9DaC9QNBzvej+UnlyidBPKBG8BnZeHFJl3kpwhwEXSuZICHokH9Yhc2Wh6M2JWW9pOFhJONU8CuVb+fvF1JoqnPALsbx6iee8hiulhfTwpC0Ovzs44bDApZGTkcz0WjxjKkX7zoAdLBus= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=XxpvlVIq; arc=none smtp.client-ip=74.125.224.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="XxpvlVIq" Received: by mail-yx1-f45.google.com with SMTP id 956f58d0204a3-640d4f2f13dso1393377d50.1 for ; Thu, 22 Jan 2026 10:34:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769106896; x=1769711696; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=Mq5VJmqRAo0xyjSAtScAIcpCkrPE7TyUs2+qpNnChkY=; b=XxpvlVIqZ0IfofRHGQWWylRC8GxN6bMSvOumG22vLgb70sXqTdtQQ4nIfPF9Cxx3e5 pPnCEElIZbmJYql7WVfHzGuLe/0FadSSkAe2lqglPK3BSr7RiKPZhssCxe/mAqlKeAF6 J7PIJqKol1SaiKgCko7LUQ9mtmgOYljv7PzFrqVULKhcgfLp0QfhGGIWSozjTY/DBFyB 0pMjjt/iXpsBdEkODfxCeQHXdBZu5JhO7J1Un8gsbheNMJhD7Tips95nl9qAMJNGDUPj Kh1o40OaK5q6RjSh9sFqvPdXeKs6Xp2fiNENJqMbCi/aisBXDReBstKpLeZELuHYCw1R p61g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769106896; x=1769711696; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=Mq5VJmqRAo0xyjSAtScAIcpCkrPE7TyUs2+qpNnChkY=; b=qDVHnBn0BDgCFLpxU2FOA1i0W1HaimVa2H1wfN99CCMyT3iTCkaZwJr3+g8Tt1+ShE 5g2VpORiixr3f7XzWGj6nHwmX3mMaiFLZZwsexK7E6gziZJfv8mMYdb+tNSb4oszWEl1 TxS73IoIWv98UOdtU9P4LQe560ObelcCrIzs+9jm42BZNV38nucns1jNWYKMh3MjDuBZ MsPz7G2dxBpSvzQfaNmSve3gWTCOPoGpiALCKBvX1dndhNfVZDnS4yV0dwAXNOdN9iPs 9eWlmE6DpOLABxy2Vnrwx3hp3mslnZ6XSPHfE+8S2izCTsVTVIrEYQaVjTfrgIlPeaQf sklw== X-Forwarded-Encrypted: i=1; AJvYcCXGTns8NfVsV4EeEtXNkPqyRCdIxMNCWf+lwp9+qv1/ZAwabPUD0aYRNE75vH/MR/wYrp57Do2XyiHvyJM=@vger.kernel.org X-Gm-Message-State: AOJu0YyQmrhIzxL7sHzwHxnm6mfWYklnb5CO0Tk5d7eXsDHpj2zjvgvY 8WywJYV7dDsG2eWXP9NUJX7HrrFIc/rX+iByBSTZm4t0Essx8AYKS4Yp X-Gm-Gg: AZuq6aJfbwGX1zfitPEjr8ykWCurAPF+Bo+NiLLF7owc2egk0LnV+IQCC+y8wltJzMh L9KfnHHqwqCwu90AqovIX60Q2LU9kyo+xGYA2/rWbI23ExJvlIzWMpCiB2MYhh84RXQ/8BvnA59 TwLcDJ/GfU74iyQzdzbedPfEVDhjq+orhNYxKvpwnbX131KKlVW3ZT+S06iMUSwZTRg39RLbVvo M9cUXenQhLBk2fA5Epj/axjjIQZvOdO87U/Nk3SU5Hz8B78JK1hHpUdIR7gfSzZ53ZvfmoqmdYa iSUBdJPOlAxKza6wy7g6UPhSUTKcDAwVx2z8MSYg23Qs7uxbjDuISW03w3XOdnKPENwga87Jray +UCJIe4CC3xodITIIO5dNppOylj4685FdCy6f6ppVL1mvShhn+g63c6WwJc8cpSu8dkuWLxVK8z +HXqQTMuGWKQ== X-Received: by 2002:a05:690e:13c3:b0:644:71e8:cd02 with SMTP id 956f58d0204a3-6495be6c0aamr352932d50.4.1769106895892; Thu, 22 Jan 2026 10:34:55 -0800 (PST) Received: from localhost ([2a03:2880:25ff:47::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-649170bebaesm9858332d50.21.2026.01.22.10.34.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 10:34:55 -0800 (PST) From: Joshua Hahn To: Akinobu Mita Cc: Michal Hocko , linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, hannes@cmpxchg.org, david@kernel.org, zhengqi.arch@bytedance.com, shakeel.butt@linux.dev, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com, rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net, ying.huang@linux.alibaba.com, apopple@nvidia.com, bingjiao@google.com, jonathan.cameron@huawei.com, pratyush.brahma@oss.qualcomm.com Subject: Re: [PATCH v4 3/3] mm/vmscan: don't demote if there is not enough free memory in the lower memory tier Date: Thu, 22 Jan 2026 13:34:53 -0500 Message-ID: <20260122183453.2619156-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hello Akinobu, I hope you are doing well! First of all, sorry for the late review on the series. I have a few questions about the problem itself, and how it is being triggered. > > > On systems with multiple memory-tiers consisting of DRAM and CXL memory, > > > the OOM killer is not invoked properly. > > > > > > Here's the command to reproduce: > > > > > > $ sudo swapoff -a > > > $ stress-ng --oomable -v --memrate 20 --memrate-bytes 10G \ > > > --memrate-rd-mbs 1 --memrate-wr-mbs 1 > > > > > > The memory usage is the number of workers specified with the --memrate > > > option multiplied by the buffer size specified with the --memrate-bytes > > > option, so please adjust it so that it exceeds the total size of the > > > installed DRAM and CXL memory. > > > > > > If swap is disabled, you can usually expect the OOM killer to terminate > > > the stress-ng process when memory usage approaches the installed memory > > > size. > > > > > > However, if multiple memory-tiers exist (multiple > > > /sys/devices/virtual/memory_tiering/memory_tier directories exist) and > > > /sys/kernel/mm/numa/demotion_enabled is true, the OOM killer will not be > > > invoked and the system will become inoperable, regardless of whether MGLRU > > > is enabled or not. > > > > > > This issue can be reproduced using NUMA emulation even on systems with > > > only DRAM. You can create two-fake memory-tiers by booting a single-node > > > system with "numa=fake=2 numa_emulation.adistance=576,704" kernel > > > parameters. [...snip...] > can_demote() is called from four places. > I tried modifying the patch to change the behavior only when can_demote() > is called from shrink_folio_list(), but the problem was not fixed > (oom did not occur). > > Similarly, changing the behavior of can_demote() when called from > can_reclaim_anon_pages(), shrink_folio_list(), and can_age_anon_pages(), > but not when called from get_swappiness(), did not fix the problem either > (oom did not occur). > > Conversely, changing the behavior only when called from get_swappiness(), > but not changing the behavior of can_reclaim_anon_pages(), > shrink_folio_list(), and can_age_anon_pages(), fixed the problem > (oom did occur). > > Therefore, it appears that the behavior of get_swappiness() is important > in this issue. This is quite mysterious. Especially because get_swappiness() is an MGLRU exclusive function, I find it quite strange that the issue you mention above occurs regardless of whether MGLRU is enabled or disabled. With MGLRU disabled, did you see the same hangs as before? Were these hangs similarly fixed by modifying the callsite in get_swappiness? On a separate note, I feel a bit uncomfortable for making this the default setting, regardless of whether there is swap space or not. Just as it is easy to create a degenerate scenario where all memory is unreclaimable and the system starts going into (wasteful) reclaim on the lower tiers, it is equally easy to create a scenario where all memory is very easily reclaimable (say, clean pagecache) and we OOM without making any attempt to free up memory on the lower tiers. Reality is likely somewhere in between. And from my perspective, as long as we have some amount of easily reclaimable memory, I don't think immediately OOMing will be helpful for the system (and even if none of the memory is easily reclaimable, we should still try doing something before killing). > > > The reason for this issue is that memory allocations do not directly > > > trigger the oom-killer, assuming that if the target node has an underlying > > > memory tier, it can always be reclaimed by demotion. This patch enforces that the opposite of this assumption is true; that even if a target node has an underlying memory tier, it can never be reclaimed by demotion. Certainly for systems with swap and some compression methods (z{ram, swap}), this new enforcement could be harmful to the system. What do you think? Again, sorry for the late review. I hope you have a great day! Joshua