From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A0EA2C52D6F for ; Wed, 21 Aug 2024 18:14:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2B8186B0155; Wed, 21 Aug 2024 14:14:33 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 268356B0156; Wed, 21 Aug 2024 14:14:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1305F6B0157; Wed, 21 Aug 2024 14:14:33 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id E9C4A6B0155 for ; Wed, 21 Aug 2024 14:14:32 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id B0FE61A0145 for ; Wed, 21 Aug 2024 18:14:32 +0000 (UTC) X-FDA: 82477052784.13.D5862BA Received: from out-180.mta0.migadu.com (out-180.mta0.migadu.com [91.218.175.180]) by imf09.hostedemail.com (Postfix) with ESMTP id ADE65140022 for ; Wed, 21 Aug 2024 18:14:30 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=xWFrkEzb; spf=pass (imf09.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724263992; h=from:from:sender: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:dkim-signature; bh=qqw3z9XEpjV/KGTSb0qDz+WvspqsTp+dFl1xRPsUBpY=; b=HvJIBZ2QrXeambE7KygsY78VE/hnF8q5Gb6CJO+Gs6/930VZtcWnjra9KcLQK+rXm+Y8lr Ju3TAio7LmjHY+pTpRYvNzKhHXAIONywu3FI8XOmckxCN4w04H4mDfrIhodU8ehj6UhU5P YP7LIdXZdxxD6gsrKOG/4aaZmnYwun4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724263992; a=rsa-sha256; cv=none; b=UOdPjTC3zUyfJU2zWSUlvdaKvPIl3WKSN+CUhLffPmnfVOXlfGMidECjrYZnSe19D15fsn pRvgw6N4szIocLSLgQ7h2uGeXXyKP85HmYl1JBuncU8+RYsbnvsSbzW0ND5jT1YW520S4+ Sg9Gm11H/mLDmDBd5AaHKomvhpJGosw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=xWFrkEzb; spf=pass (imf09.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.180 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 21 Aug 2024 11:14:22 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1724264068; 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=qqw3z9XEpjV/KGTSb0qDz+WvspqsTp+dFl1xRPsUBpY=; b=xWFrkEzbcdLTRYwDs6FME8WItV8TLl0GFhnq8kIy8c59GU0GEpNI3+P/Ndy2xOxB2lYqcI h0KN9BqDhPY4YsFsob0Yk0SgRVLg6DknfxQyxLSIjsfQpVKVucFMPJbKcnKPh6/dEaNpYP HfDqKt96GSrUafm6+CQ0OgSVN8CyR6o= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Kairui Song Cc: linux-mm@kvack.org, Andrew Morton , Matthew Wilcox , Johannes Weiner , Roman Gushchin , Nhat Pham , Michal Hocko , Chengming Zhou , Muchun Song , Chris Li , Yosry Ahmed , "Huang, Ying" , LKML Subject: Re: [PATCH] mm/swap, workingset: make anon shadow nodes memcg aware Message-ID: <67wuawgnf5os22gb2woshxve2kdkxz3pkcfdy7kcm7irj6d5tn@h42jzenif3wa> References: <20240820092359.97782-1-ryncsn@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: ADE65140022 X-Stat-Signature: 9gjos6ep6he6erbm5k8rjez1zkh4is6w X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1724264070-185551 X-HE-Meta: U2FsdGVkX1+vfDDuXAZEB/RGAX7MkNpwfVMx75D0ovhWSZMzSiR/3AvPfqKOZFhPscD/sCteSNJaX42A9CoqrF0aDKxyEbwUTW603hkNcY4XuFKEEqa1jKhk6ByaF8OrVJiybA9hQORYp9c5U1FpGwa/mYkofPRfSPy+YYywSq+wl4iZvQFr9htMwdJS9xYWr8+8fANvClOb4cucsZmiZxn4vqQwToOpG6P+6TyB0siSUG/MGdV0OyGEAy00SwnreInpKl9ZDheoHUmQ0Odv3TNVNSx0IFULiAxa2uCRXz7F1z4chnr1ErhjMNtQ8LmwtF47vSbNZonZrd2YnKGhE1+auCuIBK1IshzvmSLJcKDNYitOcMdytE9nUU6Em6gUt9EJ9Ts2YSKh0/ECET1YqyaOfnoILOH0R9bdedDz0iuVUvJYXA4Be+cx5/Xv4TUtWQg0m4CMfixiezWcBIbYDGx6DtPHeEMLlzYRW3wzqCjcuHXEn9uyOO6wFbefNxO8yAxbjuPsWsK4xT/nsS3n8xbpfVsK6mkopTM8WXS/oIwHkvPZNfcH7INZ3D9/eLBQpy66Rf4VayZc8pyLp/CaHLmYThbpPHvF9eQAV23wZtNuBG6NPTjmYaHudGsTCNLKLyNMJngwiYpWPH6OjOHlbNQoFZ7D87Jy97j2eFjSImmPedsbgV0UTrt5uoScbFed/XMLiz2yTxixG3wp2MtA+MkCiLJvn/aqIpKM381Jy7RAVJGDYTGdVBpPnPC36TJkp5iOHFSZq6buKAwfEBwjg0+YavVwppmZX9cLZEH9Omf0wCU/v/Nc6xpABCRQHw/sM4wlL5TGSlSPfv9nsDi4yctVPvbMV7q4Hc8HClDX5vlEg2Djp2hCmCVh6mLidNe7FFkFzh+6SOWF8i8DjLeo4Z0RJrcKp6+BQNkcIRsRUvDvHafRaPk16a78y6q3rlT0yJN7ckArvynhplqPfn7 VVDy82FO p5S3J/zQbqGoa8Eu2rK9zb3Pq18s49mm0Ew8jBgxmCYAmr3GVOFLfvqlKGgjXszzsR1RdaOqRYf1q8U9pd1SUPCzFtXG0Q2iICR4Z3S4sHOX5oBmNzojKRlDkA6X4O+yU8Dq6pMHM5nHt/51eJWeoWCrIDA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Aug 22, 2024 at 01:35:29AM GMT, Kairui Song wrote: > Shakeel Butt 于 2024年8月21日周三 08:22写道： [...] > > Hi, Thanks for the comments. > > > Is this a real issue? Have you seen systems in the production with > > large amount of memory occupied by anon shadow entries? This is still > > limited to the amount of swap a cgroup is allowed to use. > > No, this patch is cherry picked from previous series, this help > separating the shadows to different cgroup properly according to my > test, and reduces the lock contention of list_lru by a lot combined > with later patches. Not very convincing on its own indeed, so I > hesitated to send it alone. > So, list_lru lock contention is the problem you are trying to solve. Without this patch, do you see less impact of your list_lru series? Anyways this patch is not the right way to solve the list_lru lock contention issue. > > The reason I am asking is that this solution is worse than the perceived > > problem at least to me. With this patch, the kernel will be charging > > unrelated cgroups for the memory of swap xarray nodes during global > > reclaim and proactive reclaim. > > Yes, this could be a problem. > > I didn't observe this happening frequently with tests though, SWAP > tends to cluster the SWAP allocations, and reclaiming tends to batch > reclaim pages, so usually there is a fair high chance that shadows of > pages of the same memcg stay on the same node. > > It could end up completely random when the SWAP device is getting > fragmented or reclaim is struggling though. In actual production, fragmentation and memory over-commit is very normal. So, such scenarios would occure more often. > > > You can reduce this weirdness by using set_active_memcg() in > > add_to_swap_cache() using the given folio's memcg but still you have the > > case of multiple unrelated folios and shadow entries of different > > cgroups within the same node. For filesystem case, the userspace can > > control which files are shared between different cgroups and has more > > control on it. That is not the case for swap space. > > Right, this fix is not perfect, it's arguable if this new behaviour is > better or worse than before. There is some ongoing work from the SWAP > side so things may get fixed differently in the future, but I'll also > check if this patch can be improved. Yeah with mTHP we can reevaluate this approach.