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 7EB8FC3DA4A for ; Fri, 26 Jul 2024 18:13:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A31BF6B008C; Fri, 26 Jul 2024 14:13:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E1706B0092; Fri, 26 Jul 2024 14:13:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A9146B0093; Fri, 26 Jul 2024 14:13:37 -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 6C2C96B008C for ; Fri, 26 Jul 2024 14:13:37 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id D074BA6AF2 for ; Fri, 26 Jul 2024 18:13:36 +0000 (UTC) X-FDA: 82382701632.14.785CBD6 Received: from mail-qv1-f42.google.com (mail-qv1-f42.google.com [209.85.219.42]) by imf21.hostedemail.com (Postfix) with ESMTP id 06F031C0009 for ; Fri, 26 Jul 2024 18:13:34 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DV1haCFa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1722017574; a=rsa-sha256; cv=none; b=4G6RWUR1hE2HMTT6T2KGcJ4fWp0kwZet/5zo5mGv5tyu8j+CJOsK4KTGhUbEWH3wU1GLTE 8j88SnY4vvtYHYBNFks6zANu0Kb2YIbA8+LB8/q2rSJDidhe+AXNrvedDnpcmHQX1G+dFu BIFLlKbAnqQ53BWeluK/lzaz9zZipuc= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=DV1haCFa; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf21.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.42 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1722017574; 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=8yl+brwVcmXERPrivxbwrAeUpUiEtoSaIUh7zOM8yeA=; b=bbGF2vzQiViprZkY1Oih8I2uxsz20KKAR5glcPEOUs68iH6zvn5HJctFBlMdr4xMAVu1cG DwyRVI+/gzcHfB0ubStwW8FVwoU1qFc5dpsbaxKIdfP1uzG7boR1GHPXJowFE/RmWaMwky UEsRJtBGwQvREL916NVJ8MiiipI5qfM= Received: by mail-qv1-f42.google.com with SMTP id 6a1803df08f44-6ad86f3cc34so5504296d6.1 for ; Fri, 26 Jul 2024 11:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1722017614; x=1722622414; 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=8yl+brwVcmXERPrivxbwrAeUpUiEtoSaIUh7zOM8yeA=; b=DV1haCFaxlSVdRd/errzQIDwKfk/ZC3w+ldnW90z20zxvqbQGYCKNVWaUfMMYTlkPI lyhWZtFAgMJey+/sTtq0quLdqIdsAs4QOojOYltDTB/wjKNq2QjikpWfNsZsgztG4HZm RZYdGbl8n/WSmRTfQ970zNz3mG8Qq73YLPAsX/MpMPoE46xjIkCEKGEXejGDxBs6sXBz jwJTBGfOK5/poI02K/IX91e0CV3PrP1bzU1ZNkO0vj8jaqpXmDcLCQYAaX+6gNT/SG32 XaCODi8rhKK/ng4fFRQy6Pq/HeKu2AwtlosJa3QqZjhu2q7dQEATqV11cXWThvDqBPg+ PfvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722017614; x=1722622414; 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=8yl+brwVcmXERPrivxbwrAeUpUiEtoSaIUh7zOM8yeA=; b=PMonXo/I2r+2y4DKDx0xt9ctZlJQO53T4RT7/H1EqOOzhUVJ6XXihRYDa9bD0Qgqux Nn2liAWx563YV+08r9GRzhe1NcMxPw12rgKYHRMVyIOUNBVXJJted4RZ/aWlR81EdXj7 GW8bNMreXvMfXCYHLUFYHh4DezEwNCqFItpIY7OZxkZMzMEAJgYCzTPBwevJzMocBE5A feVKvmf7M0xqHSC9nv51n+zagrV1EOBFlCQG3D8SPdEt2a35I7HLpvnOkYfW2121MScN 8S+vyYEsJIMgg6qmRc6yaitpCxxaiqYHiHCQFUwag+aiU4i9/jLFeHfpZ0Cn4F4dgRUi EZ7g== X-Forwarded-Encrypted: i=1; AJvYcCV65aR1VB5oUNf2F0BQ+jdPyQrVmoe/6KPniNRTU3BmyeEZ+v7NKsf1Cuzys2GumndObQWywSFYLmYsMh0faPd6fuE= X-Gm-Message-State: AOJu0Yz/BZjeZfsOYUkHMjjg+Y3IgrXS7iu7zpLWeJ7pXvBIOOwolygh USp9jz6x8RZdpNoGx89Mm4H+toi7bNYjhsgUO3lTBYb5vc65Do5+0USQzrqxsJLv/FARoffH7D8 kNdR3i5vY6bsAkaojoa5f6ieF6Yw= X-Google-Smtp-Source: AGHT+IH9k1ccca51XmPFByCp0c4IKFLOi0edvS+N8+/KUOVzMdJ0gAgPleHDU17zFghi+hDIwlh9UKl9KNkpnOFZhuQ= X-Received: by 2002:a05:6214:4105:b0:6b5:4573:4ac5 with SMTP id 6a1803df08f44-6bb55a82e7cmr6503326d6.45.1722017613881; Fri, 26 Jul 2024 11:13:33 -0700 (PDT) MIME-Version: 1.0 References: <20240706022523.1104080-1-flintglass@gmail.com> In-Reply-To: From: Nhat Pham Date: Fri, 26 Jul 2024 11:13:21 -0700 Message-ID: Subject: Re: [PATCH v2 0/6] mm: zswap: global shrinker fix and proactive shrink To: Takero Funaki Cc: Johannes Weiner , Yosry Ahmed , 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-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 06F031C0009 X-Stat-Signature: 4s71e3k58ru9utazia155c1ifau6cpkb X-Rspam-User: X-HE-Tag: 1722017614-332097 X-HE-Meta: U2FsdGVkX19qDIKlqUhXp66ZWgLeDe0ua9mzZw8yT8P7zY9EGEKJuU0UjmaOXBbzz8kQi1gag+zhJY1PTWLaTXPrjO6lQm/I8KqQknfNwciAwQxx/K4aybMp0ntyvSyFOt8qNYoKLiRwcqNazV7ov97MD6I6jcXoV1huMMOVX9ElPozJ1+Z9K8/B3PijhIXyR6DjEZbpmgcSkOkm/8FN2QMopmXyAKrk4IRy46rKlrorlU862HdkMy9qAnCYjMaWV5OcZu0czRsJ1NbWRhTI4SsnAGP2C6h5XcV51RDfy+NUkqpfMjcEAzsdMs08z9jEpGZYBkUwsOG/lSu2aaQkBnf9DV/XlL5QUW4ZksTXj3EMLZhir3T+1TdjfOMt4F6zveIwlqKXIWlFEKGSgiLZrWjNbSnEZTON46lqt3S3LwnbXiH+gMIIlfjl8V+OSp3y1JjDCwr+5D3Q+0Eh+WgYUVoqrsnt6joDNKFVofc86MIbX2ME8LOTYhiHb6V0krLDYu47q9ef8FmIdDNyGxDIlvrgVsl9+AVIvhVLkUp7xZao6WcYK/zXS/5vxzizdh21P1BBN7KNbXFKkXgS7VG/e00sfSoR8p/O4w8VglaE2oH2tgMHqHfyICky19dtIRuceRnoLPBkFBYiOUDfBhAuVzxdNCYrZDkEt/Ngf1GJtQ4ZF2uN7/WItmid3vhSt7Fj/zQMuzQkiEs5fQsV3CR/56keaJvt/pMxr7wxPHlYG5A8O9+8SSFqJqpfkXEG+sJOtHzWcqI4Ce/TajopADG0iMzPRIEZJ0bUZXCQLRoKUIepBMjXEaPHHz2mR+LAveJPhl6JaMBWINuK+ldYN/bYQY8FFHusNkXBdjvBSBsuWco1KzWfdCEodxTAHX8d4KmbJiMceBKis2RFgdaNMNBWbrQt4y2jsS5exbrfSrNAEXCtYgpOwrfsZ3GMrDbNu19OSaE9PT5tCj5PlfqPGxk /+WY7XQL eDPohcF+BRUhKYtBkZULLq35lNI8JAQH4tQMlaMJZBGEdQYK05dtEW3/G4Bk1w4gdVbirhPDQ52zPz9ujE8sXYwRa05mnfDDRGOzvtHcGzB5/L1NjDnUPBTnvrDNaVx4zztvlHhHZGSGqMShwDrmE9kxuTKc3BbLGh7gtCgO9w9TT/iL8brGAJ0NNzRyhXuESyivWeiExTnPm9JwxvAiGuLafixQajlZQyXVgRkt2FnPUY2bdZgaZ6Lguv7BAWK2Xyp2v2HzQtOKY7GLPRn+iqm6bI0kE+byacfI3/6fSO7S2RAxzGhP+2gCYaPqSiKsT76R/ X-Bogosity: Ham, tests=bogofilter, spamicity=0.010085, 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 Mon, Jul 15, 2024 at 1:20=E2=80=AFAM Takero Funaki wrote: > > 2024=E5=B9=B47=E6=9C=8813=E6=97=A5(=E5=9C=9F) 8:02 Nhat Pham : > > It was tested on an Azure VM with SSD-backed storage. The total IOPS > was capped at 4K IOPS by the VM host. The max throughput of the global > shrinker was around 16 MB/s. Proactive shrinking cannot prevent > pool_limit_hit since memory allocation can be on the order of GB/s. > (The benchmark script allocates 2 GB sequentially, which was > compressed to 1.3 GB, while the zswap pool was limited to 200 MB.) Hmmm I noticed that in a lot of other swap read/write paths (in __read_swap_cache_async(), or in shrink_lruvec()), we are doing block device plugging (blk_{start|finish}_plug()). The global shrinker path, however, is currently not doing this - it's triggered in a workqueue, separate from all these reclaim paths. I wonder if there are any values to doing the same for zswap global shrinker. We do acquire a mutex (which can sleep) for every page, which can unplug, but IIUC we only sleep when the mutex is currently held by another task, and the mutex is per-CPU. The compression algorithm is usually non-sleeping as well (for e.g, zstd). So maybe there could be improvement in throughput here? (Btw - friendly reminder that everyone should use zsmalloc as the default := )) Anyway, I haven't really played with this, and I don't have the right setup that mimics your use case. If you do decide to give this a shot, let me know :)