Message ID | 20240126083015.3557006-1-chengming.zhou@linux.dev |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:e09d:b0:103:945f:af90 with SMTP id gm29csp538568dyb; Fri, 26 Jan 2024 01:19:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFYP4zStClzIcj9w0WAQnhXGsmOaPaHXHyXKUZcQDPWhIIUafpQmI1pDBY7U7Al8B8pXuBJ X-Received: by 2002:a05:6a20:914f:b0:19c:80b6:42ad with SMTP id x15-20020a056a20914f00b0019c80b642admr690906pzc.53.1706260749535; Fri, 26 Jan 2024 01:19:09 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706260749; cv=pass; d=google.com; s=arc-20160816; b=B/tURhAKwEGDvdM/LOuj+I9wrMR/imS2dzZC6f77lTuazq15vsxpZ3GG4tlRV9VqtH IZKbgAUwcsnuXRWH/m+EYlYzsoezpSuqoo/v5t163FPrqhgc6hm7ZlOonJxcUp+Xx5RD LBg3XWeMe5ktA9HveaGfiGDCWdKLMw+vDkBXdsmNhGk1k1NdfJQMULGtb7O0cx4MR/Vn SqwL8M5zEeGHxbGOI7WiJFby3c3dXEs5bO9Bvtbxq1s3eDASS/G1gWCG/cErNLZDm4IQ /NI6RXQp4XuQa3Fvbv8woFyi84941r67h7oDt4EiuKHJrgmTiOliffzfn7SoP4chIv7r kySA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=ul4Yj318/IPfN1mLm2oHYHwsIT4SRkZ2huqI5cSMQ1M=; fh=Cv2JnOWBhkv0KX+IPsfdzGF6FV7WfkXK2IUIUnpyRYY=; b=MS9md6DjGTw75WWCBnD19uVVuVhdDetbYTXZULY4PBJlDBfYLMWl24FJTKRxFeosl6 fiJbG9Q0g3m/XrD7DyKcqDtqtx1F0llJb49bMKuUgNAqfL9nyNhmZcgt2nRzncvtPS43 nmas0ytazcq66awivvxx8vh9FPoSaVdUeuaR607ORdMFqAKD5vwgYvij/YFGAW/K9s+G au3z2/85kjU7MJoORQcrHW8G4G9wTO1Oynsjfx6G5459sCOYvGgx1UCebDNT0NjFmLhh fbl4BFkkSCynT+bjquftIBKE/pji5sNh6BJvjG+VawWGWqqmuekSTpeR+TZDSCskL9Vb zZIg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=t38FsnZ1; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id r59-20020a17090a43c100b00290c935cdd4si2864746pjg.83.2024.01.26.01.19.09 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jan 2024 01:19:09 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@linux.dev header.s=key1 header.b=t38FsnZ1; arc=pass (i=1 spf=pass spfdomain=linux.dev dkim=pass dkdomain=linux.dev dmarc=pass fromdomain=linux.dev); spf=pass (google.com: domain of linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-39764-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linux.dev Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 96B242829FA for <ouuuleilei@gmail.com>; Fri, 26 Jan 2024 09:17:22 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 9AD101BF4D; Fri, 26 Jan 2024 08:32:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="t38FsnZ1" Received: from out-175.mta1.migadu.com (out-175.mta1.migadu.com [95.215.58.175]) (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 0CA753C07 for <linux-kernel@vger.kernel.org>; Fri, 26 Jan 2024 08:31:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.175 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706257922; cv=none; b=C+olsVUaX+gLXEQtmVnz0iIUZ4HABfW5JvYsHn1NjyQd1kjQA+X4eFW0T6hEkBC3ECxWOsRLlxdk15+OSLgb2DNgiQ6Ai3QU47++UdMcC8iTrYf1kLuNv4FETKNFzJnzG51zvSpstVtFArqkExVIeC46r7S2TIDUFj2X1XwAou8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706257922; c=relaxed/simple; bh=beAV2xZzm1pfX7BpJJ4sLYGMc2yhgnU5EF3GNuNtmDc=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=QD+HgMw6t5/umHpmdEUKq/g4KZSfX/SCqF6J3Dv8AbCXsV7/++PUiJLgN57pc+T7i7K03Jz8gDVtgNW1fwSHUJXoUEP758Yatwm2mR8APpjHyu39Fxhm0xyHJoFmCyzM4JfLSZC1c/l4H/n4DXLV3IHaPMBOx+eykg3hp9wXNrU= 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=t38FsnZ1; arc=none smtp.client-ip=95.215.58.175 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 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1706257917; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=ul4Yj318/IPfN1mLm2oHYHwsIT4SRkZ2huqI5cSMQ1M=; b=t38FsnZ1Muc6VXvBr4BPW2hj/FxunpwClITeZKYaX+yMeSCpB5klMmu1qlnZQ4WYYk6bbD 1GiLoLKVo/wWom1Stp4eARMN/cROOzoWLXX5GTzdXy3ExsHOa9BKTaRBTPCWWV6Uvk/adX uepBwPm12pYL45eeBg0ZxwSF2w5x0dg= From: chengming.zhou@linux.dev To: hannes@cmpxchg.org, yosryahmed@google.com, nphamcs@gmail.com, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, chengming.zhou@linux.dev, Chengming Zhou <zhouchengming@bytedance.com> Subject: [PATCH 1/2] mm/zswap: don't return LRU_SKIP if we have dropped lru lock Date: Fri, 26 Jan 2024 08:30:14 +0000 Message-Id: <20240126083015.3557006-1-chengming.zhou@linux.dev> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789144071602927543 X-GMAIL-MSGID: 1789144071602927543 |
Series |
[1/2] mm/zswap: don't return LRU_SKIP if we have dropped lru lock
|
|
Commit Message
Chengming Zhou
Jan. 26, 2024, 8:30 a.m. UTC
From: Chengming Zhou <zhouchengming@bytedance.com> LRU_SKIP can only be returned if we don't ever dropped lru lock, or we need to return LRU_RETRY to restart from the head of lru list. Actually we may need to introduce another LRU_STOP to really terminate the ongoing shrinking scan process, when we encounter a warm page already in the swap cache. The current list_lru implementation doesn't have this function to early break from __list_lru_walk_one. Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> --- mm/zswap.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
Comments
On Fri, Jan 26, 2024 at 08:30:14AM +0000, chengming.zhou@linux.dev wrote: > From: Chengming Zhou <zhouchengming@bytedance.com> > > LRU_SKIP can only be returned if we don't ever dropped lru lock, or > we need to return LRU_RETRY to restart from the head of lru list. Good catch. Can you mention the possible consequences in the log? "Otherwise, the iteration might continue from a cursor position that was freed while the locks were dropped."? > Actually we may need to introduce another LRU_STOP to really terminate > the ongoing shrinking scan process, when we encounter a warm page > already in the swap cache. The current list_lru implementation > doesn't have this function to early break from __list_lru_walk_one. > > Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") > Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org>
On Fri, Jan 26, 2024 at 12:31 AM <chengming.zhou@linux.dev> wrote: > > From: Chengming Zhou <zhouchengming@bytedance.com> > > LRU_SKIP can only be returned if we don't ever dropped lru lock, or > we need to return LRU_RETRY to restart from the head of lru list. Ooops. You're right! I just double checked and only LRU_REMOVED_RETRY and LRU_RETRY indicate we might have dropped the lock. My bad. > > Actually we may need to introduce another LRU_STOP to really terminate > the ongoing shrinking scan process, when we encounter a warm page Yup. This is what I was trying (and failing) to do. To be honest, this needs to be even stronger: short-circuit ALL concurrent/ongoing zswap shrinker scan processes that are touching this memcg (as they will also shrink into warmer regions going forward). But that's a bit more engineering to do. LRU_STOP, which stops this scan process, would be a good place to start. > already in the swap cache. The current list_lru implementation > doesn't have this function to early break from __list_lru_walk_one. > > Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") > Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> Reviewed-by: Nhat Pham <nphamcs@gmail.com> > --- > mm/zswap.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 00e90b9b5417..81cb3790e0dd 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -901,10 +901,8 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o > * into the warmer region. We should terminate shrinking (if we're in the dynamic > * shrinker context). > */ > - if (writeback_result == -EEXIST && encountered_page_in_swapcache) { > - ret = LRU_SKIP; > + if (writeback_result == -EEXIST && encountered_page_in_swapcache) > *encountered_page_in_swapcache = true; > - } > > goto put_unlock; > } > -- > 2.40.1 >
On 2024/1/26 22:28, Johannes Weiner wrote: > On Fri, Jan 26, 2024 at 08:30:14AM +0000, chengming.zhou@linux.dev wrote: >> From: Chengming Zhou <zhouchengming@bytedance.com> >> >> LRU_SKIP can only be returned if we don't ever dropped lru lock, or >> we need to return LRU_RETRY to restart from the head of lru list. > > Good catch. Can you mention the possible consequences in the log? > > "Otherwise, the iteration might continue from a cursor position that > was freed while the locks were dropped."? Good, will do. > >> Actually we may need to introduce another LRU_STOP to really terminate >> the ongoing shrinking scan process, when we encounter a warm page >> already in the swap cache. The current list_lru implementation >> doesn't have this function to early break from __list_lru_walk_one. >> >> Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") >> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> > > Acked-by: Johannes Weiner <hannes@cmpxchg.org> Thanks.
On 2024/1/27 02:01, Nhat Pham wrote: > On Fri, Jan 26, 2024 at 12:31 AM <chengming.zhou@linux.dev> wrote: >> >> From: Chengming Zhou <zhouchengming@bytedance.com> >> >> LRU_SKIP can only be returned if we don't ever dropped lru lock, or >> we need to return LRU_RETRY to restart from the head of lru list. > > Ooops. You're right! I just double checked and only LRU_REMOVED_RETRY > and LRU_RETRY indicate we might have dropped the lock. My bad. > >> >> Actually we may need to introduce another LRU_STOP to really terminate >> the ongoing shrinking scan process, when we encounter a warm page > > Yup. This is what I was trying (and failing) to do. To be honest, this > needs to be even stronger: short-circuit ALL concurrent/ongoing zswap > shrinker scan processes that are touching this memcg (as they will > also shrink into warmer regions going forward). But that's a bit more > engineering to do. LRU_STOP, which stops this scan process, would be a > good place to start. Good suggestion, will look into that more later. > >> already in the swap cache. The current list_lru implementation >> doesn't have this function to early break from __list_lru_walk_one. >> >> Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") >> Signed-off-by: Chengming Zhou <zhouchengming@bytedance.com> > > Reviewed-by: Nhat Pham <nphamcs@gmail.com> Thanks. > >> --- >> mm/zswap.c | 4 +--- >> 1 file changed, 1 insertion(+), 3 deletions(-) >> >> diff --git a/mm/zswap.c b/mm/zswap.c >> index 00e90b9b5417..81cb3790e0dd 100644 >> --- a/mm/zswap.c >> +++ b/mm/zswap.c >> @@ -901,10 +901,8 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o >> * into the warmer region. We should terminate shrinking (if we're in the dynamic >> * shrinker context). >> */ >> - if (writeback_result == -EEXIST && encountered_page_in_swapcache) { >> - ret = LRU_SKIP; >> + if (writeback_result == -EEXIST && encountered_page_in_swapcache) >> *encountered_page_in_swapcache = true; >> - } >> >> goto put_unlock; >> } >> -- >> 2.40.1 >>
diff --git a/mm/zswap.c b/mm/zswap.c index 00e90b9b5417..81cb3790e0dd 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -901,10 +901,8 @@ static enum lru_status shrink_memcg_cb(struct list_head *item, struct list_lru_o * into the warmer region. We should terminate shrinking (if we're in the dynamic * shrinker context). */ - if (writeback_result == -EEXIST && encountered_page_in_swapcache) { - ret = LRU_SKIP; + if (writeback_result == -EEXIST && encountered_page_in_swapcache) *encountered_page_in_swapcache = true; - } goto put_unlock; }