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 2DDD1C48BF6 for ; Sat, 17 Feb 2024 05:12:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79CCE8D0005; Sat, 17 Feb 2024 00:12:07 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74D028D0001; Sat, 17 Feb 2024 00:12:07 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 614718D0005; Sat, 17 Feb 2024 00:12:07 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 52D208D0001 for ; Sat, 17 Feb 2024 00:12:07 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id E5DA31A015D for ; Sat, 17 Feb 2024 05:12:06 +0000 (UTC) X-FDA: 81800124252.10.537C5EC Received: from mail-wm1-f43.google.com (mail-wm1-f43.google.com [209.85.128.43]) by imf23.hostedemail.com (Postfix) with ESMTP id 46C13140005 for ; Sat, 17 Feb 2024 05:12:05 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AjzQ+QLg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708146725; 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=K70lgBcu7tk1H4/muC53496J1GXspshhrMHKi80019s=; b=IR6PNjPfFsNi6aH94JVe5qmrUMTMkuXxkO0pezCsoAhU7PnRqMsgChsm+VINAaBXslY2a8 ZX5tS13LRb/1U1SgmAsSUdhXpT2KHMujH0dG68Pr2FRxsu4TF6Ddl8TGgXZEpyMMzJ2EGE PmJbf/sd8fSi8etnl92qRv0+4U0W1nk= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=AjzQ+QLg; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf23.hostedemail.com: domain of yuzhao@google.com designates 209.85.128.43 as permitted sender) smtp.mailfrom=yuzhao@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708146725; a=rsa-sha256; cv=none; b=e9wWtSaKLOTYWSnRNQNZtIYm3/hiojlUdH73HtlsI0S2YbUAVzPKVE6uVoPP5UDrTBKAIx WFopkidsgjjmz3dLqQv3KyRA2q1NLQfjJXjIDxzu5OhFss/g2W3QrVOnK1MewTiMVbpOjb 013ogvdjqQ3Pzgx4l6HqhSjvWLJIq9E= Received: by mail-wm1-f43.google.com with SMTP id 5b1f17b1804b1-410acf9e776so16925e9.1 for ; Fri, 16 Feb 2024 21:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708146724; x=1708751524; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=K70lgBcu7tk1H4/muC53496J1GXspshhrMHKi80019s=; b=AjzQ+QLg9OJH6n79O5wJVGdxUdQsinyLFp7LJWIEre4wrIUFJdbD3wqZP7D1Iai+DB XOt2YozJkJmJwju78hTLV4uuXeBzCTXe181vvaXnBB0hHwmJ132pDzyMx/iXkBYonED0 MRLRqbyv/wLkzr8jRc+DUpDe5BOtHVI/bNYS2qgC2XwVu/0lFvLu8mCRZaNrQhzdXTxo 3FU2zkJLZe0xGVn9zbF3v5WG5OIkVUDL9eWHbIkyozgtCvx3we9dyVk2et3QKxBwEqJz 9XVhwDZZAhUZG/4l0cx+IuHAv1AEzkyrd6q/3HZIKh9XmRAwTwY+entRDBH4hyzM7ruz Kvng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708146724; x=1708751524; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=K70lgBcu7tk1H4/muC53496J1GXspshhrMHKi80019s=; b=SU2Q9Vnud6hYXjGso0dFKBYzb2CKnzJhiXXSBmmzZ7DlamFARxdPM+95KlaJ9Q8zpl A7EMTeUYXakhkeFL86qkWj+oyShZQiCE5IY3+33q//L4Rfp/n5w1sHGXe76+9e1JjQXT P2vLuQ2nOXxaSozgbW9lYnIn/c0y2YoHsOF1aXpQGf7wh8w2Ukq07t8rX45dbG2mrZWL KfF2xjUON8OiiqU/oi7cZSGTrsKHFI563bcCCDg+WS9uN/fFQ2MecftOAsdFdPyVUSJV YKHuEVosDgdykafJGAVYLT5p2jBNSVvFOC54i1DlrTytamA83m16/yQXudUy/QYjTScj HKhQ== X-Forwarded-Encrypted: i=1; AJvYcCWhANo+6/cFNiW7mkRzd6VBWvQpoM6YvWJQLOm29Xta5ppvJywswLH8X0QIJctVmcpc/xCdcWc6eandsH1cQD0EsM8= X-Gm-Message-State: AOJu0YyeWC2o+6NXBzKULUZU5FuyQIdiqzbphRXeBrhUb+5vRJY0WM+d zgXAcxpm7RTdT/HLMK1AI54qCdfZ4jxwp2oFKyCIJSGs4remryOU4QR1Noxm+wCn/Z+eAPI9Y9b slmX56ZEwDSsGIYAKp9waBQfzZ1RJ6UkpNkIK X-Google-Smtp-Source: AGHT+IHJdbdFpifcl1UxAGM4ZsFIq+6YMU1UQp37BMHZQeazrv3ssuETT8xCek0PnCH/RB8r5jwu2AXXnwsisbeqkMg= X-Received: by 2002:a05:600c:3493:b0:411:f6b6:faf5 with SMTP id a19-20020a05600c349300b00411f6b6faf5mr91584wmq.3.1708146723521; Fri, 16 Feb 2024 21:12:03 -0800 (PST) MIME-Version: 1.0 References: <20240208061825.36640-1-byungchul@sk.com> <20240216072434.GC32626@system.software.com> In-Reply-To: <20240216072434.GC32626@system.software.com> From: Yu Zhao Date: Sat, 17 Feb 2024 00:11:25 -0500 Message-ID: Subject: Re: [PATCH] mm, vmscan: Don't turn on cache_trim_mode at the highest scan priority To: Byungchul Park Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Stat-Signature: ht1saigp5z3m7ge89hsfzgcf4jbygosn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 46C13140005 X-HE-Tag: 1708146725-70299 X-HE-Meta: U2FsdGVkX1/SGsdOCeipeRp236JKM+aN0fUtgagCd2hVOtIqV3q60INEIDVElG/4SLV1+NAZs0rcH+Do6qDW+YEUx0QUIqONXky+6V6E8Qnzj7DF+T3mYYTwz+HvlYFiCUx2vNXvAIy2KyPDDiL1rxb1jgimGqPeI7UtA7eGBvYLrril3eevRf1h78U14zIJqaOY3WR19aYUr1tZs93NK4xK3ldUK3GufZb2K9V9afHbfzi6f38i3CQGPrSkm/MkoX7JnOOV3oZ8oK3wvYgH1lss9ilMV6iEBvWeXgYO/NJEHsrPUHlGdAnNQxP2jP6UgyvLVE+vEY6lS0cOpojdlzrleLng5U6qP0EvEcy5Gjbc+nr1dNMEjgoeGET8sy9fYkZP0/lSmAD01vwqyTVxSkiEhuqJ3vaCl18yeWMnQ8NOtkM2QgqsDna1URoHljlKWgQNFbHu5qqVVyzYQprjbX/0YHHrUKcF9wB8e+PJ9N8on9apiErjUj9I4uwC3LJyP/bpXA0g2pihDrD2mYp3kzOG2F0lqwGRlnfJmTqaKQxQ9QDlU3OVP5v2J2Nm436XLuRXNwFaWBZbnXXrEyNi4k/GN828PXRj9fe/Yfk+aP9abP2GMizG2VCGhBd5D3u+5GTq/grpGzjxhuszpseoqksAgV/sf980rlI3xgKsg1Uo/Xyq7GutmQFYzDflf1+QbuP4s9hZc94eIcfVnxu6AHQsTFHLsFdRmSBLx+cW9ZCmDgwxnnVoyJGWYjXrXGo75ZpcxrC7F+D/f+OIuPJZK4E9SJK7hCWH4tXwlU6dI1iEzvGTLzc4ivuz72TM7JKjnJekl97Y0pjmt/dy10dBNPAt9T0MiiMera/tWDI021TBLGJUx45+tfaunq3ny1+QaLBGjvkMfAzUcZrgNZQpU4Y61ZhDelQt+hDczA9RVgwdse43x7iUpmaWV32P2II1FBCYGld4JQsmXnRQXY5 KOJ5fdiS 9dc0/zBJoGsqj7L512ONXj1kmK7zBRVUsb8GZaggKW2SDp4c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, 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 Fri, Feb 16, 2024 at 2:24=E2=80=AFAM Byungchul Park w= rote: > > On Fri, Feb 16, 2024 at 12:55:17AM -0500, Yu Zhao wrote: > > On Thu, Feb 8, 2024 at 1:18=E2=80=AFAM Byungchul Park wrote: > > > > > > With cache_trim_mode on, reclaim logic doesn't bother reclaiming anon > > > pages. However, it should be more careful to turn on the mode because > > > it's going to prevent anon pages from reclaimed even if there are hug= e > > > ammount of anon pages that are very cold so should be reclaimed. Even > > > worse, that can lead kswapd_failures to be MAX_RECLAIM_RETRIES and st= op > > > until direct reclaim eventually works to resume kswapd. > > > > Is a theory or something observed in the real world? If it's the > > former, would this change risk breaking existing use cases? It's the > > I faced the latter case. > > > latter, where are the performance numbers to show what it looks like > > before and after this patch? Let me ask again: where are the performance numbers to show what it looks like before and after this patch? > Before: > > Whenever the system meets the condition to turn on cache_trim_mode but > few cache pages to trim, kswapd fails without scanning anon pages that > are plenty and cold for sure and it retries 8 times and looks *stopped > for ever*. > > After: > > When the system meets the condition to turn on cache_trim_mode but few > cache pages to trim, kswapd finally works at the highest scan priority. > So kswap looks working well even in the same condition. These are not performance numbers -- what test cases can prove what's described here? > > > Signed-off-by: Byungchul Park > > > --- > > > mm/vmscan.c | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > > > diff --git a/mm/vmscan.c b/mm/vmscan.c > > > index bba207f41b14..25b55fdc0d41 100644 > > > --- a/mm/vmscan.c > > > +++ b/mm/vmscan.c > > > @@ -2268,7 +2268,8 @@ static void prepare_scan_control(pg_data_t *pgd= at, struct scan_control *sc) > > > * anonymous pages. > > > */ > > > file =3D lruvec_page_state(target_lruvec, NR_INACTIVE_FILE); > > > - if (file >> sc->priority && !(sc->may_deactivate & DEACTIVATE= _FILE)) > > > + if (sc->priority !=3D 1 && file >> sc->priority & > > > > Why 1? > > It means the highest scan priority. The priority goes from DEF_PRIORITY > to 1. This is not true -- sc->priority can go all the way to zero. > Byungchul > > > > + !(sc->may_deactivate & DEACTIVATE_FILE)) > > > sc->cache_trim_mode =3D 1; > > > else > > > sc->cache_trim_mode =3D 0;