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 28C7CC3DA62 for ; Wed, 17 Jul 2024 17:49:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 965706B0088; Wed, 17 Jul 2024 13:49:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 914E16B0089; Wed, 17 Jul 2024 13:49:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B5F46B0092; Wed, 17 Jul 2024 13:49:38 -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 5CB856B0088 for ; Wed, 17 Jul 2024 13:49:38 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D506E40BF6 for ; Wed, 17 Jul 2024 17:49:37 +0000 (UTC) X-FDA: 82349981994.09.FF388EF Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com [209.85.219.179]) by imf28.hostedemail.com (Postfix) with ESMTP id 974F6C0005 for ; Wed, 17 Jul 2024 17:49:34 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AnwPGRtw; spf=pass (imf28.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721238534; 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=r7IStd/KRzefG9mLooWDUvkj+uQ4fDVlUMU9FjL0Lp4=; b=hYsw0b46uJFCXXD7xgp/iNyl/bqMjqOBmWFrFj04NtjpBxeGJ3/6I4/AkceG2Lzxdni+o1 9URB5/z5VQc6GzosIG+ieGTNhYjswEqeoKRkPYNHjQc1nLO8Oh61ABWT4H3//strPJxrhL ONjIlU8YETN/WsRQQ+adram9Tohs5eA= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721238534; a=rsa-sha256; cv=none; b=W2ejWjb7sSHSyHjwlY3lOPMMNntgQxhGdw8cjIWefiAh54CJnnXq2nvlZMTcP29oxQ9GBJ VOE7MC+7mp2wa+xbtmviUGWtuSincsXjDMRXdlrk90BxqeRmfKtVsN0mgzX7Lm+oGRd9zH silkSZgjzmluEfEmLW6BQJ5mRuQRrdc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=AnwPGRtw; spf=pass (imf28.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.179 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f179.google.com with SMTP id 3f1490d57ef6-e03a17a50a9so50204276.1 for ; Wed, 17 Jul 2024 10:49:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721238574; x=1721843374; 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=r7IStd/KRzefG9mLooWDUvkj+uQ4fDVlUMU9FjL0Lp4=; b=AnwPGRtwN0gsFnCmRnu+d/u3d+A9R6QgqmBE2sjTlO8C7oqWUu3MbqVby9OMzj+KO7 9GrNVmChyr00MY3R7fjUyZYNJVgh00WXdcHdnKaExSbcU5AlDlGBx44gpL/1f7diCurR w/FgqVnjJVpspLFeubtN33N86/IdrW7G5XcdPAPgpspu2BbEVTEp4IC31wHmPR1l99zg rAzNOupAfwD6HiGqZ9hxJfXUIJgHv5VgFFhzTQe0va56cZPjZmBAgWrakRfuSLf5mczR 4HnVrJak/Mo6MCz15cHRfCrNSOL1oMEqIlQFgTEWasB7wcHZ63gBVbhzzmmrl/XolsqS 2Z5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721238574; x=1721843374; 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=r7IStd/KRzefG9mLooWDUvkj+uQ4fDVlUMU9FjL0Lp4=; b=DpZR+ejWBG3sqn0rr47JJWc8SZnQBogvES89lkQEO4CKthmdRkbhiXJL50wvHm4onL e7ZExUqxmQIxdj7Num96eje2XKPamDoYnmOFXO0gr2HDJ02oUenAOSkkuUaXEKbbb0tE /58+cMo/QWE04OjmgNKedSPCQ3fTTWqaYjgtwv5Ntm/esoVlYP40RWHmC2ZQXigttUNR EMd51gKSJbIuPt0yJksZFOfO5199WtG2oDTG5OA6kqt6p+Pt/DluMidrb3oRQio/tYYG 4aKs0CHGIZHIkyA/zD6GMSlQGmdmK/sz/OJj37+kzhGhfxJ7LDpK17h7Nf3a/nZNQoRY IBIw== X-Forwarded-Encrypted: i=1; AJvYcCUSTZwvC9OiOHc03ZDUP3lO8XBBAssKHw6Wn7e9Q8kzdrnto54H9PbFrjMvVg5nImRRvjqW41eF75vwI3ngQdCcCoU= X-Gm-Message-State: AOJu0Ywz1mMixGLjG83UdgrrpXM4MYfUAC8ne8Q0miHE8VsrRV9IvFZ6 Bfnm6UMz+QIxq5h1bcxHK6CcrYidcOUEyfHnufi96zsz2Ue/0gD9QDw96nVwbhFR+wBeV9P8i1U BO/DJA/5DLhAO0BKontMSKxpzYfU= X-Google-Smtp-Source: AGHT+IF+3ePAZRTQ0ohZAzihaoPtnFNUgFOaTbtH6oWBWeBWki6l7XK/0hMSS5HAUgxBHEs1QsMxJa5K0L510VXoWjo= X-Received: by 2002:a05:6902:1004:b0:e05:f40e:440c with SMTP id 3f1490d57ef6-e05febc0a76mr187623276.44.1721238573561; Wed, 17 Jul 2024 10:49:33 -0700 (PDT) MIME-Version: 1.0 References: <20240706022523.1104080-1-flintglass@gmail.com> In-Reply-To: From: Nhat Pham Date: Wed, 17 Jul 2024 10:49:22 -0700 Message-ID: Subject: Re: [PATCH v2 0/6] mm: zswap: global shrinker fix and proactive shrink To: Yosry Ahmed Cc: Takero Funaki , Johannes Weiner , Chengming Zhou , Jonathan Corbet , Andrew Morton , Domenico Cerasuolo , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: tspg735wmy3yzh6sed3qzihirpthsg53 X-Rspamd-Queue-Id: 974F6C0005 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1721238574-191408 X-HE-Meta: U2FsdGVkX18/IongDISFPtzRGhSrLdaVTmIbl/CfiicXityDtmVz2/Z8DatzhbPTLLiGmU1Ufd0eiU8JdgqSTtFycLOfwHatWNB2hEHbyA/ivDXvsmvlBooCVAlR5udmHbPTtGiI8IIayZlxUchQMxc4MaoySSupXdQTvlWaoivMpwDKEIHqT91HnZfE9m23WStPd0Dpg/5wonHnXg6z1k/86dizDTQxdBn2yabuT3vYruewmg+4fcgaQ4vHb1CIYuUHyYT4Py9rO+5/hJx/DLsLfT1regGaxY5yFUS5bKVazteur6fOdnL1DI4wWDkpt6v+NkuC+hYG59n2QWdWCCfMmiTppR0YWFogtBkHDG0NuTwrWOvF3THnFMCkoOGK3Z4J/eTJeoYo0MOrBPSPC9aSwydnLjCO6seo9fjvjyicCjwMRPrNsIGwnn0LKn71lmF+AHXJ992yE2j7CMZFVm/sar2Y/DZfePMw3DC5rQNq5cMllwcb9H8Wzfi2oyw2ZHYUhPFxpat+mzOKPT7HMkiF03KkEF/9IBEASJnYza3X4TxVtTILFwdapwGNdzLOuyW71Teas4jcwo6XTuuA1FAIaATvUuE619jHlYz4+8kRY0yz9QBnEdL1bBR1bIJeTEGYzi8JgH8nXERDFoWPOxWv4hkh1en9NJcW52YknGDeKZRHMcBLvCCGgx+nwTKSQ5/sZn9ctFS2I5oQztuCNwplt6KwP6jsJX5eVLKSth8HDLxcC80Qh35Mttvc9seLmypHOeqWLxukUBBTH99BhmvdGK5rxSfEtQLU6coCMIiuAQP9N8oCKLhB+dtrviHOGR2lDNx7zQCFHjVhxJlk4v0fVaokwDTTicDDzBIvcV5EVaidIr/pmR6vFox4Hqb9RdBqu6CLQ3gp5NifQtTxgxsDqVMApl/7kYVs8ReAKMT+eFYkikxXrPWOat2V6oStRxorkQdjJknuY89JwvU HWtxN2/E lTdd3tZtwCXfcGl0rrft2HTDMP9QwkRnDX/MLdPyaXi/+AJflaNL3P/l6eo6EoZ0kNW2QjfUFjL8JeU3OPysaaaTwDkSttJSnsxPrJEvUYh2O4C2bQqLo5C3teSj1UFlHkWoffYGKHqtiYvEvWhZJVkqHjbCh6VewYLVW/e9WEwR652UAPnFsVGaXoX7S3cX5UCgMrEfmiGSFHzmuuTdmK86ZCnm+mvwGRbmQ4NSNP4U3g2mo1kj1TY2bGdfm722X93kp0DXOyAcR2T9G73ualrVOEZeXKiGPtpWTMjAdeoQwodudDQgLfHSTDPqAFVvvsvzK X-Bogosity: Ham, tests=bogofilter, spamicity=0.000291, 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 Tue, Jul 16, 2024 at 7:53=E2=80=AFPM Yosry Ahmed = wrote: > > [..] > > > > > My concern is that we are knowingly (and perhaps unnecessarily) > > > creating an LRU inversion here - preferring swapping out the rejected > > > pages over the colder pages in the zswap pool. Shouldn't it be the > > > other way around? For instance, can we spiral into the following > > > scenario: > > > > > > 1. zswap pool becomes full. > > > 2. Memory is still tight, so anonymous memory will be reclaimed. zswa= p > > > keeps rejecting incoming pages, and putting a hold on the global > > > shrinker. > > > 3. The pages that are swapped out are warmer than the ones stored in > > > the zswap pool, so they will be more likely to be swapped in (which, > > > IIUC, will also further delay the global shrinker). > > > > > > and the cycle keeps going on and on? > > > > I agree this does not follow LRU, but I think the LRU priority > > inversion is unavoidable once the pool limit is hit. > > The accept_thr_percent should be lowered to reduce the probability of > > LRU inversion if it matters. (it is why I implemented proactive > > shrinker.) > > Why? > > Let's take a step back. You are suggesting that we throttle zswap > writeback to allow reclaim to swapout warmer pages to swap device. As > Nhat said, we are proliferating LRU inversion instead of fixing it. > > I think I had a similar discussion with Johannes about this before, > and we discussed that if zswap becomes full, we should instead > throttle reclaim and allow zswap writeback to proceed (i.e. the > opposite of what this series is doing). This would be similar to how > we throttle reclaim today to wait for dirty pages to be written back. > I completely agree with this analysis and proposal - it's somewhat similar to what I have in mind, but more fleshed out :) > This should reduce/fix the LRU inversion instead of proliferating it, > and it should reduce the total amout of IO as colder pages should go > to disk while warmer pages go to zswap. I am wondering if we can reuse > the reclaim_throttle() mechanism here. > > One concern I have is that we will also throttle file pages if we use > reclaim_throttle(), since I don't see per-type throttling there. This > could be fine, since we similarly throttle zswap reclaim if there are > too many dirty file pages. I am not super familiar with reclaim > throttling, so maybe I missed something obvious or there is a better > way, but I believe that from a high level this should be the right way > to go. I don't think we have any infrastructure for anon-only throttling in vmscan logic, but it sounds trivial to implement if necessary :) > > I actually think if we do this properly, and throttle reclaim when > zswap becomes full, we may be able to drop the acceptance hysteresis > and rely on the throttling mechanism to make sure we stop reclaim > until we free up enough space in zswap to avoid consistently hitting > the limit, but this could be a future extension. Agree - this hysteresis heuristics needs to die. IMHO, I think we should still have the proactive global shrinking action that Takero is proposing in patch 3. The throttling is nice, but it'd be even nicer if we can get ahead of that :) > > Johannes, any thoughts here? > > Anyway, since patches 1-2 are independent of the rest of the series, > feel free to send them separately, and we can continue the discussion > on the best way forward for the rest of the series. +1.