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 D61B1C27C77 for ; Tue, 11 Jun 2024 15:51:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 540606B00A2; Tue, 11 Jun 2024 11:51:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EFF56B00A3; Tue, 11 Jun 2024 11:51:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36A8A6B00A4; Tue, 11 Jun 2024 11:51:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 183996B00A2 for ; Tue, 11 Jun 2024 11:51:17 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 632101614E3 for ; Tue, 11 Jun 2024 15:51:16 +0000 (UTC) X-FDA: 82219046952.22.2F1EB05 Received: from mail-yb1-f173.google.com (mail-yb1-f173.google.com [209.85.219.173]) by imf06.hostedemail.com (Postfix) with ESMTP id 999B2180006 for ; Tue, 11 Jun 2024 15:51:14 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fk1EVY23; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.173 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=1718121074; 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=pgGuDE+XrbAgHUHE3XCxL9tGB/eU0RinDylZrRbr6yM=; b=qlkVHY4r2+TEBtyIFcD6ZM1D0vgUjuR1dXEnqA/gmxujgC0HXfVwPqVVdBj8WSAnH6xIRC KKB9Lww0igX/tnadwPA8kQkUuqA8lPifZa+u42F8m+2JBS0SZKYuLQa74uTxby3S9K2rQ6 //r127jJJp8PqhjEowkRMx6Av3mpRMU= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=fk1EVY23; spf=pass (imf06.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.173 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718121074; a=rsa-sha256; cv=none; b=qovecnFPCCC45MYOpCcPWSeVS0eyNFKnQPyTCMatSGj3Xr3l7nV2050+qpyh2ga1zcLEYv kZYC9/aTVIuPwAQOmtsLZ3BX6LGxeVHrzoak5qq0L4jA0NITarZs39LU6HOr6YbOLDa9ua nQce0cTZqJK37EVnsBggp5lgEwX/IgU= Received: by mail-yb1-f173.google.com with SMTP id 3f1490d57ef6-dfaff6bf125so4238624276.3 for ; Tue, 11 Jun 2024 08:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718121073; x=1718725873; 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=pgGuDE+XrbAgHUHE3XCxL9tGB/eU0RinDylZrRbr6yM=; b=fk1EVY23GS/D88h5ZE9jAfHhvw1zbYnfNK/k5YVXYevhj7Tdk8dM70gD5s3Sc/r5Hn INgIJbqPryW2BomXCXdvJoXE+4rhZKmEcTvXnnZa8ea1y5NfITxAxo91uw3zOj9eGMOU SsVdrnaFrfAniQFpLBPyS73xN4AfM4YBZOj6LrvxDns0PAyfm788XM0MNT17NT25yfyh 8bBbRkvcvnR/gpqwc3nwhmNXC4xAVFAwhiOliCJ8eGCy+8KzFs5BvA0WVkFeb9gDPHv7 H0RaGJPZM9XlVskmbAf6IjC4lYmVlTuFRHjYid2R5Ja1T2e9cUOXDf9RPabZJmOcx7d9 LI0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718121073; x=1718725873; 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=pgGuDE+XrbAgHUHE3XCxL9tGB/eU0RinDylZrRbr6yM=; b=FmqgAGXWH0GH8ssNMMW4tsRhhGekcks9pIgaPNC5OnRKj9NKY0LQZ2xsxRUZoVeEar RKWJdi4gYPpJCBkwdZj3KybSzBvLOspcxrz2rFkCeM7lDORXfRoMjaF2lCMCmPNOdmlh aoobp9TJ+AZru9MWStjQvpP1OChgn9npj14uYS98TMSWykwW/ku+l99JKrDKJSHL9VJY WPbxdvxEvKg6bPoZ9yfeBnhcMw38MUNMMPqMgSrtF0UBwwbBXCcVQfx6wK84M+F5KXKq lTQaPt8Ufo+48Vo7Z+uvXhfzif+yM4mlsKe9xoTQtTEGw0DJ2zZDucbPA+9B/ikBccFb k3HQ== X-Forwarded-Encrypted: i=1; AJvYcCUDI3yBtnczYCugCcfVgyis39KhMH4WcP2KT7OdE4PqeUm6FnCTJOuipjCGN40wRdm9Mqj+UE4aKW7JJ/VIiJFLsRQ= X-Gm-Message-State: AOJu0Yx2FzIvZmDD9R/uo2MXGk6aPke8tdhbtgN1dzCubvCpxC3GbSz6 MXyqxvy80+za+Z5LVkSkxpziljmI+CRKQVu9mYqTJ0v/nZmYTEOGjEBRcPQKYDg33Qp+gYcBJV1 wS6/55zURWpBjGPscrn+fWloP13s= X-Google-Smtp-Source: AGHT+IHNNEtnsE4csjfuwepPpDKNjhB/oWwbjvYHlUleiX67QfVK6AwXQmjdNC8kRnlAGwWx3GMQw0USiyj3gZlMLaI= X-Received: by 2002:a25:ef45:0:b0:df7:695a:1cee with SMTP id 3f1490d57ef6-dfaf66d1473mr12865314276.50.1718121073472; Tue, 11 Jun 2024 08:51:13 -0700 (PDT) MIME-Version: 1.0 References: <20240608155316.451600-1-flintglass@gmail.com> <20240608155316.451600-3-flintglass@gmail.com> In-Reply-To: From: Nhat Pham Date: Tue, 11 Jun 2024 08:51:02 -0700 Message-ID: Subject: Re: [PATCH v1 2/3] mm: zswap: fix global shrinker error handling logic To: Takero Funaki Cc: Yosry Ahmed , 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-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 999B2180006 X-Stat-Signature: s875ukuz44ehooep8iacgouj8xucaczd X-HE-Tag: 1718121074-957538 X-HE-Meta: U2FsdGVkX18s9o5mSP2QmbbUj1JZKBoQt7fYmI86VHDBdy8+uMTRxySupfijhqSD7rEdieh93KRCsbF2rtk5lTtt1dngecks6ZqstTYmURVHfKvDNz+RDPQ8lG4K22FuwvHxYCyMVydLWXOI1b82LIfK8rX073U8Mll6h0AUSJSMNdFR2al8uTwYD1F1hXIui/5R7iM3eCatmXmvDsPCzfUesXjTT9AgWIJj7ZvGXNwXc0V7gDadcbe4CHVILf9N1dscJ52gq3y66wKMNbc3lAnRYNGzjAARAeEUqR0H7dxa13gc7WXdNKaLmaCsSRXBnRKZq/MwEcVVreLI3mGvJfsqvIOMs8AnAAwQWcTJai9t3rTXXXP9AoAcSpAed+snFw9quU+/uS/93U/ILTV9brAxtRF/UZaKLGvYaGxSA2YuPmR8imvvoDffgldXUCtdxW1QssETigWDYwxTnxYpmEqkZQrm6gAQyQpxL7XYEjum71DC2tamGJpnIQZgpBQQ3XTFgwhrlow0ugYNJ7qsaLa0Wlfv/qGqlCRzm5xM8g9gYUHm5thTFipnsaqiLEcZNBUx2eTFW7ew3SGfy0Ic5eWGdivVkkTl5gz9l6StQPiEXBhb4fcko5eQazkQ8ikMiHbjZnjGFSzLkNpQvseCtowfxP5cm/1yF99jsI9Pt+xzqmHIOgmmTd+fsELjMBXINA12RDoS1ezDgdl14l//+eCTI74lKtV6O9ldcvzHh/OKieX+nfnPB78GxGkhcgq3wIBy+vjo+WzrW5r94S3AxJsUtefo/cgxhIwP2nyHEWOS5XxhuTQ0blNtR56iAo4Nf5n25bfY8ZMtMe+GWu3F1naEUp4rGInCo/VPZPOQfGB6AHSQLMwY8S0gxnIqKiBYly2IVWenjc7Sng0/hrIFUE/xTqrPZpJ39AL4KzcXyP8rdtXM9R9TsXfG6X7dPLwYL2fRK9JwHFUnpGDj08e vAGjC+bU 4vymulUZFe1PjMRk82bT0qNSHSjFlNcJ1tjsDo2hFSFklCn9xL+wetXMtJVLG5C7nuZYaBw9SzIvMYfI9reMpZrsgtyuwy93tVuVrcWam5EJBXLlDcA6b9NQozARYdm9HkQAqoGtGpJuxfStDko5HF8Zzjjrijsidpw+pe9mOrg3qGnWWNQlT+hkmipqo6oxmb1ivlpiCXzW8Kpl1Qvq5/sPO16qAIhMDfWYvOUkXJcrQ00i6alhilM69QFNJUcEfjdwWRlTZ/TDmxxkVDkRp1fdSLGrO9ux0p+9c X-Bogosity: Ham, tests=bogofilter, spamicity=0.005013, 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, Jun 11, 2024 at 8:21=E2=80=AFAM Takero Funaki wrote: > > > Since shrink_worker evicts only one page per tree walk when there is > only one memcg using zswap, I believe this is the intended behavior. I don't think this is the intended behavior :) It's a holdover from the old zswap reclaiming behaviors. 1. In the past, we used to shrink one object per shrink worker call. This is crazy. 2. We then move the LRU from the allocator level to zswap level, and shrink one object at a time until the pool can accept new pages (i.e under the acceptance threshold). 3. When we separate the LRU to per-(memcg, node), we keep the shrink-one-at-a-time part, but do it round-robin style on each of the (memcg, node) combination. It's time to optimize this. 4th time's the charm! > Even if we choose to break the loop more aggressively, it would only > be postponing the problem because pool_limit_hit will trigger the > worker again. > > I agree the existing approach is inefficient. It might be better to > change the 1 page in a round-robin strategy. We can play with a bigger batch. 1. Most straightforward idea is to just use a bigger constant (32? 64? 128?= ) 2. We can try to shrink until accept for each memcg, hoping that the round robin selection maintains fairness in the long run - but this can be a bad idea in the short run for the memcg selected. At the very least, this should try to respect the protected area for each lruvec. This might still come into conflict with the zswap shrinker though (since the protection is best-effort). 3. Proportional reclaim - a variant of what we're doing in get_scan_count() for page reclaim? scan =3D lruvec_size - lruvec_size * protection / (cgroup_size + 1); protection is derived from memory.min or memory.low of the cgroup, and cgroup_size is the memory usage of the cgroup. lruvec_size maybe we can substitute with the number of (reclaimable/unprotected?) zswap objects in the (node, memcg) lru?