From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0E60C31B828 for ; Tue, 4 Aug 2026 04:19:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785817198; cv=none; b=sb8s2iiLwcMcOpAhsdv1xNvNiFCoSE/0p6KWoLqJun8U73yiG/cG2Wn2KwZpn5BUbLwv0u5gTOKqTIEFLD2f+GE24xnTySH1yyqKeZvWLUOE5lo4NnUNjU43Gv+xwus6p5bL1J63D4gISlxD8pz+aEolAlyGFco5q9n4/KWXlSo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785817198; c=relaxed/simple; bh=857Br6aTp5l+WJvJXuFAMD1wggshwYAJuLkSrFhDmKI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kiVNj+eJPCTITVwIaya3tlaEVp1Rpnw1/kovt5lKnQraPJi7fPhhHg4w7y5xXoV17wesaMsodorvtwZ5S1VMybsc+4gzG9NCFJNQ3HZgCjyOtT1cr96kRMGXZht7R4hO3pzZGeMUyJgDMewKpIVBU4r8ODWfmiSGzi99DSSHYXQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=U19WtwYS; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="U19WtwYS" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785815514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=175EbZHBL3F1dS8YR8Z8r9c4iZSEBgt9aiiE8BBHiOk=; b=U19WtwYSY+G/DxpEAUy0NvLxRrtwwQB3fY/g3kYKVDJ5jSacqCxKWrwubGS+4hgGL6Ly+K K9Z0ZUvXaCyC89C5BoKR8x3xVMQ5ztYfY0QEsUYtkfYX2sTWdQi5kUb5LDM6nnh9fppXoK veIcqGqIT/+lBi64DhqGRk+uyws/YcI= Date: Tue, 4 Aug 2026 11:51:38 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v3 0/3] make unused huge shrinker memcg aware To: "David Hildenbrand (Arm)" , hughd@google.com, baolin.wang@linux.alibaba.com, usama.arif@linux.dev, brauner@kernel.org, akpm@linux-foundation.org, Qi Zheng Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <944bfc30-68e4-4ccb-8b00-f0f86d27cb56@kernel.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <944bfc30-68e4-4ccb-8b00-f0f86d27cb56@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT Hi David, On 8/3/26 8:21 PM, David Hildenbrand (Arm) wrote: > On 8/3/26 10:46, Qi Zheng wrote: >> From: Qi Zheng > > I'm missing description and motivation here. My bad, since v1 was just a single patch, I got lazy and didn't bother adding a cover letter description later on. > > This is only about shrinking huge pages that span end of shmem files. > > Is this really a problem? And if so, why? Yes, this is a real-world problem that we encountered in production. The root cause is that shmem unused shrinker used to be non-memcg-aware. This could lead to a scenario where reclaim triggered by one memcg A reclaims the shmem of another memcg B, causing unexpected impact on it. Even worse, memcg A might have no reclaimable shmem at all, making this completely useless work and incurring some performance overhead. such as: tid 11340 comm scanner locked a page for 182264 us! kstack: unlock_page+1 split_huge_page_to_list+3135 shmem_unused_huge_shrink+767 super_cache_scan+329 do_shrink_slab+291 shrink_slab+533 shrink_node+400 do_try_to_free_pages+206 try_to_free_mem_cgroup_pages+262 try_charge_memcg+591 mem_cgroup_charge+136 __handle_mm_fault+2431 handle_mm_fault+194 do_user_addr_fault+462 __do_page_fault+176 do_page_fault+48 page_fault+62 Later, with Usama's patch [1], the shmem unused shrinker is no longer triggered during memcg-level reclaim. But this actually doesn't make sense either, since we can clearly just reclaim from memcg A individuallty. [1]. https://lore.kernel.org/all/20260715103516.2410175-1-usama.arif@linux.dev/ Thanks, Qi >