From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (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 89E5136EA87 for ; Thu, 22 Jan 2026 16:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.179 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769099967; cv=none; b=N7Mm4sbEs/jge1MwvkC5OXiq8+B+nIqwHOJCGmECNej1vDcTCWsNJGzBGoyWLajaec8ZRlQZA4yVSvyzQ4p0hmd7sDjmSjaVZsD4VR5ETO06kbqacqafQIl3vy8/o03PhMSRyPzyEXsQCtxg+A8VmX/KBqqTlZeJXgND6C90ENQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769099967; c=relaxed/simple; bh=XorEDbyyvoKRZ9z/e0bILVETPN9UaeqR5myzu2mQX4M=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=MKaLlIALLmxn1OQeADvk3ZNJcxYku2iTFEt9PNAE40lffU6lj17EfA9y1RhFM0XY1ebZ3sGt1g1r50KCMac3M2hP+w08tEu8idh0YLI5VD1YFlJQyZ5zrVX+fNk4RmX3HBAmLHsy29tUOe/K2KyyS49+wNp1NASRVaYPiSFtm/4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=FbAkhhDG; arc=none smtp.client-ip=209.85.160.179 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="FbAkhhDG" Received: by mail-qt1-f179.google.com with SMTP id d75a77b69052e-502a2370e4fso9063851cf.3 for ; Thu, 22 Jan 2026 08:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1769099959; x=1769704759; 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=26F4T6+OWgQyYilpWpKxSqIZyd62LthQzewXe3OU7ww=; b=FbAkhhDGaL/LJRvLBdoqZpZTg3R6nNzghJFBq+PLl3XLyONiy/zlF9kFuRJ5XxHTTd QPydGb1Y6JildzqZqgFlj7GudxflYtozVBlMkK24WT+FKAGyeUbsVgHKEZeCklpjdevR C01g8+hYB2E8v7zeaDMJaqYuoIukpUP64o9dQiaodV51dfBjx0YkUWGtvI9V/qKTU/2p g0RIQXVFppV3+hKU5f8D//Yh/8NVctdczdSD6xrQ3EdtSjF/sOq1+6pnhdeOWC44cJWC 6UMotKbjZXHHnnCXroV1Eupwcnca2WUgBt0WHiMMdQvzNyfkblc4RriH4g++zr1DZdp8 b2yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769099959; x=1769704759; 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=26F4T6+OWgQyYilpWpKxSqIZyd62LthQzewXe3OU7ww=; b=DBrpX5gxt6MVYNj2m1bBh5JGu9Fmiwv3mdHPlcB+qXj4ZpaTIQqTTNbg9cW3WppWbr 1TGQDlMNn4w4KMtSN//HQbry6pfJM0Ph4jrfmBlBAsK8rw6jB5ekoVY3/qlUGxBtbm9s dEO7VG3pRK9d1gq/TjBG6HzP83XvYv2fBYPaQh/0mOaSD0kUoXLhWhn+5eF5tUT0I1Sc m8Ly+vhGyimlan6aXtG8HbPpLOH9exxKs0QQFU6wde6edq0PfyJKRIz2FxAlPUh6P9F/ +JTeTf3Fwcbes0G4OIL4se+H6LiolRwYHX69A24R5edad+XrBzqaXUym28eoc5tTQYh7 ZGOA== X-Forwarded-Encrypted: i=1; AJvYcCU5BkR/lSTKY/CVuFNrClxwQhBzf5hlX9pMCWz21ATPfNyK9oZdPe/g7ma6vGIuRy/BtiEpvBnyz1Fnkvc=@vger.kernel.org X-Gm-Message-State: AOJu0YyRPhCO+WycgUDcGqnt/fqUrpWCawLBetju7bNO5S/iE0iQARRy 67gHX6k1CUjeLFTieDqRK4hRnrvKbnYoZck3ihLKuxLJ8qWz6bH+zNgXUX8npb27lzE= X-Gm-Gg: AZuq6aLStOnqzi0XiLbr4nFlJBgWT5r2z9jklIMb8bcFjC+DaYKJJvkgbSKQUJuCJd0 nq28ugDKO/zu8CnEUupOeFlRmk2QNSyrO62P1GL6hSxxfX/q+TKZz7+lmbzy5cFNVQ+9795Ipsv j23LKaRpViCi8NDrKpTwOD0ECukWQNhXNzdI6IHqX/bkj6QQZypM5ATWIvR7bD7r/z+wmenUmpP 8NmFF1hQ0FE5Nhy7d6sY25zHdrORYd2IBLOgu3MUUWjf7MWEiGkgGVc0g1bCXaSMSyPfQdPyuUU Eoc3WzUycqPcE9pzEvmyGMus2r6eaW6j0r1r5IuytBrSixTiy0bBHAsZLGaVqlnHfE3fC13fWxB Fjl1umyfs10geTkR+/3Xx/PDnz65b9u/BJFeRPVGpdZLgWUbsxlxj5oU0t3BSbgWKxx5lv76uKG MJIYDyuAgPta7/XxmeGx7wkVNK/HtIgiwZMdCxYUmuHubzz6QHrNtiaWADGs+Q4Jycz0sXgg== X-Received: by 2002:a05:622a:18a7:b0:500:d108:275b with SMTP id d75a77b69052e-502f775b653mr2055011cf.5.1769099958557; Thu, 22 Jan 2026 08:39:18 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8946e7fa675sm43565766d6.35.2026.01.22.08.39.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 08:39:18 -0800 (PST) Date: Thu, 22 Jan 2026 11:38:46 -0500 From: Gregory Price 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, 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 Message-ID: References: <20260113081453.8293-1-akinobu.mita@gmail.com> <20260113081453.8293-4-akinobu.mita@gmail.com> 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: On Thu, Jan 22, 2026 at 09:32:51AM +0900, Akinobu Mita wrote: > Almost all of the execution time is consumed by folio_alloc_swap(), > and analysis using Flame Graph reveals that spinlock contention is > occurring in the call path __mem_cgroup_try_charge_swap -> > __memcg_memory_event -> cgroup_file_notify. > > In this reproduction procedure, no swap is configured, and calls to > folio_alloc_swap() always fail. To avoid spinlock contention, I tried > modifying the source code to return -ENOMEM without calling > folio_alloc_swap(), but this caused other lock contention > (lruvec->lru_lock in evict_folios()) in several other places, so it > did not work around the problem. Doesn't this suggest what I mentioned earlier? If you don't demote when the target node is full, then you're removing a memory pressure signal from the lower node and reclaim won't ever clean up the lower node to make room for future demotions. I might be missing something here, though, is your system completely out of memory at this point? Presumably you're hitting direct reclaim and not just waking up kswapd because things are locking up. If there's no swap and no where to demote, then this all sounds like normal OOM behavior. Does this whole thing go away if you configure some swap space? > > When demotion_enabled is true, if there is no free memory on the target > node during memory allocation, even if there is no swap device, demotion > may be able to move anonymous pages to a lower node and free up memory, > so more anonymous pages become candidates for eviction. > However, if free memory on the target node for demotion runs out, > various processes will perform similar operations in search of free > memory, wasting time on lock contention. > > Reducing lock contention or changing the eviction process is also an > interesting solution, but at present I have not come up with any workaround > other than disabling demotion when free memory on lower-level nodes is > exhausted. The lock contention seems like a symptom, not the cause. The cause appears to be that you're out of memory with no swap configured. ~Gregory