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 DACB4C3DA49 for ; Wed, 17 Jul 2024 02:53:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5B28A6B0083; Tue, 16 Jul 2024 22:53:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53B2D6B009C; Tue, 16 Jul 2024 22:53:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DBA46B009E; Tue, 16 Jul 2024 22:53:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 1B9136B0083 for ; Tue, 16 Jul 2024 22:53:50 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9F8F6A1CF6 for ; Wed, 17 Jul 2024 02:53:49 +0000 (UTC) X-FDA: 82347724578.10.8173E17 Received: from mail-ej1-f44.google.com (mail-ej1-f44.google.com [209.85.218.44]) by imf19.hostedemail.com (Postfix) with ESMTP id D41801A000A for ; Wed, 17 Jul 2024 02:53:47 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZS031lRM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721184796; a=rsa-sha256; cv=none; b=1pND/e0litEOnvA7/oGK6Db0rEReo1EGEXkacqMpOFElke9PF5tIGa5vRbNl3nPQBhsByW YZSaM8nrtmlqCyCPqr3xwCrnIa1t8+Lx7NhBBS238tLgYI9R6Imz/KYmgo42YCOiToAcOD avVmwcpENa9CDxqdY0TDOD2cJGteofw= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=ZS031lRM; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.44 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721184796; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=yEGEQC6kdWCldeHXYChp8fv+9XVImMxRQifNP0QHeHw=; b=dx8xIJuHMiIosBXiDHHQGWt8hlDMNblHGkFgf9x3SM46adZ3EDi1R4DzRm99ktXlTXP4s9 Z0gIMxw1mj+hfJLGqityHojzRO98CVUeSs7BJA0O5UgeQILhYUfQ0ytAlqkt4c8ObIL9/e os8R04tBMFuiICd1EBjogNHZxL9Pb7A= Received: by mail-ej1-f44.google.com with SMTP id a640c23a62f3a-a77e5929033so732176766b.0 for ; Tue, 16 Jul 2024 19:53:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1721184826; x=1721789626; darn=kvack.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=yEGEQC6kdWCldeHXYChp8fv+9XVImMxRQifNP0QHeHw=; b=ZS031lRM+lWAgQ0r/We6EtRU/dGhJ39n5pbFX1KMzuN6kq+XoNLiH9oZx+SzHlm7fr J+dH4i6NJzDML9TjJy6rYRtnKJFwRqfKmrZUVnseIBRLgJrrBYKuRb+5N51v8F/y2SUH VPFHbMUpDvYT1iBabWU+dnXY9uIq6a2qXkLbo1fPgT8z53zQWO0RaOVkuo+ZWvPQCKt7 JwHOzo5Tmo1yf8U9cByEkrqsVJ/cBckcmC2EJF9Xbw4riuX0JR1tvwldfCdsn7LOonTu IJb+0Stu74bETN5n0bsqiuEFQ8Z7hEF/uLHnWAJQFfDaotDqnHc2Grk7mDyNaP64czcL rCHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721184826; x=1721789626; h=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=yEGEQC6kdWCldeHXYChp8fv+9XVImMxRQifNP0QHeHw=; b=kPaGi+XlujsdKqnlCj5Bibo3iX7i7UcJpkgWGN8SaGEhIAWh+qcyc70qsVc0ms3WpL CwfdPCUAAuK8DfmQHDkTtzhBNwyrWBfpAv4KD7mAHxcUw6FV+rps11UCBYtO7feze1+U V/83yWHoqAw/Mc1XunRIbI8U5HrlocCps7A0s0uL4AlUo8LAzlMYvBE5uXQ9v0WcvWC3 UojMyQveHBhbvV1TOImDY5uHqIRKokPOhGGyzmX4Cc7L509nLHfM8cm7cxdOUH32ZQlZ ddZGtxtIoHkxCXKxUqLknG4Hf0BS5vagTEaN1UyNlRjRrM015xNXcpNcGEnda+5hrm11 T4BQ== X-Forwarded-Encrypted: i=1; AJvYcCXKWyNQcOP9LbfbnwOmbZ+eabQPkzr4vw0c/c0Rgrf7wawX6Q2aRBbCcHOakZjJ7HZ/hOLT9WXpzNtlSW3i8iEKsCs= X-Gm-Message-State: AOJu0YyiozSETD8jJeH/uOMDjBkDeOW+x5gITsEXY2lwn/Bz6St0Zx+F L2H/FjDZtnaapgRh8VblB4eHJRgSG2GqbPKgpUF0Xchzil85hI+F+Qx4Nt6uQhfUlmJlaw+OVF+ 32Jrb3q9B5ZT4YwjgpRCXfA75zh7JTUS0Fmko X-Google-Smtp-Source: AGHT+IHLCpBENZziitiorcnDoDIwuhSfSKnvt9S11GYpvblphLkDbkyMOFs/ks7fVFpa0wDqc9XixU0eg27USliSloQ= X-Received: by 2002:a17:906:88b:b0:a77:e2e3:3554 with SMTP id a640c23a62f3a-a7a011aa0a3mr20816866b.28.1721184825809; Tue, 16 Jul 2024 19:53:45 -0700 (PDT) MIME-Version: 1.0 References: <20240706022523.1104080-1-flintglass@gmail.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 16 Jul 2024 19:53:09 -0700 Message-ID: Subject: Re: [PATCH v2 0/6] mm: zswap: global shrinker fix and proactive shrink To: Takero Funaki Cc: Nhat Pham , 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" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D41801A000A X-Stat-Signature: xftjfobaky1nk6iats3cej36okqrjnwf X-Rspam-User: X-HE-Tag: 1721184827-245271 X-HE-Meta: U2FsdGVkX19pHa/GQZ80A+6WwDs/Bo/MtSiTou9Qj8xRAl7hFnjbKRVK0bby9vLQQpdN0j+KSzVSH0yw0c0m/gsFe0xOLc/wk4Eu9W9O40YKmvZRK/mDf/8UZbLQ0+73bAbwbl/QXASaD5J6fGB6kZgkIu9CoHLIBNPXTPWYX7+m4pSQJs+shyn6GXV5hQDzNb93dAZG9IbN8fA/NqXr7Zb7EiExTQpJoV38PNQM3RAGxeJy9dVDn/akFl5Nb+jMy9veRpq3DwucbEy/AKLvscKVYUWgnBNSc4BdVLq6v3i6FxX2N3s/C8dGRB6Sa8Vv7/BIr2v95X8CLBo+b8bXO8Cb/P9/K3GOitX0cPUND9n9JhLjdLlv1n48de/3/aLm6U3hEBDeakXupdzz3KeIYB2Bk352Mjq4d7WZ+7c68g1qkAiUjlu0LWJW7zI0EuYEEas9Vv+1K9TcBwedCX0RIa/bvsTNkdEOKKsMAVeX8cPYrytYkQQkrYvmPIXsV+hNe8a49kGLaHJZI5DFMbP27M6huYezK5f4ioUsPD/doYpnAKVPwwsaFBWAbJODgB3a11iOc2RZag8h814CioBTcczYtM4nIAsic6KGr+s7vu0k7NpiYUAbwpgGVZd8xFj9prgFz8FCaXo+5YqvNQOtxRZK+XzJcLo9CwgYsRzkI3s3wTggqdPczJ4ICn5joYK4UNX/1wD3rvfgOVbu5PDJJv1wCZUYu8YGA2tqTyPe0BjoVyeldE435U1LJX1egQrSRgZRPwCn8Tp6aOnjGA/ckh85PeoslMURa0E7BNmm0lVS94QcYh61O2Rc0T9vCRboKGLqvY4tUnstDDknm+fuh0Ohu3WBYvXu3avOVmw8fA3VKWQm9MDckaHOdSSrZK916vYFrk1232rhAys3fDTJFZ26UxNqsXj9YikLyve/ZiX8clyJ8IUH5JwQ863dZZF552iHT6c6ohw7/lFDz+x bxuX8q1A Z6jKmIkTTkvfMDEei7bBAebOhPaU3uFxMb7W/jQI/LZgGRkgIS79TwmNv9K6Bvz4uOEiyeDwCXaozS7zMc7j1UE52NQyxez2CJ0xugq3lRUJeGBcV6NyN7SRu0Bi1YTJ92P4ZT0SLJ8joi1UtXkcH3v57Mi3pxmXD5QGYu0bO1YgZIsA= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000090, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: [..] > > > 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. zswap > > 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. 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 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. 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.