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 53A15C47422 for ; Wed, 17 Jan 2024 19:14:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B50646B0083; Wed, 17 Jan 2024 14:14:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B00A66B0085; Wed, 17 Jan 2024 14:14:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9C8756B0088; Wed, 17 Jan 2024 14:14:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8BB516B0083 for ; Wed, 17 Jan 2024 14:14:11 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 59496C0BFB for ; Wed, 17 Jan 2024 19:14:11 +0000 (UTC) X-FDA: 81689753502.23.45EC279 Received: from mail-io1-f47.google.com (mail-io1-f47.google.com [209.85.166.47]) by imf24.hostedemail.com (Postfix) with ESMTP id 7E49D180006 for ; Wed, 17 Jan 2024 19:14:09 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hjC8mLXw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 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=1705518849; 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=2N7+b+9eTmlV+1hqRRxK5amXtgZFPEj9WEU/LCvJugc=; b=f5usqcgZT+6iNdOv0FYWJpDDEfq3zz9oL9kacLwysUb6VbOJdyJp1ZZSvFLuYYWAM3ry50 8Rh2nYEOCxebP8MjPn1ALSGJ5F/lIF8lcQaapjmwLg0TxmKG5wc73QgU8MiVZ5QnYUy0oc eXQCFNQFE2kcfCN7zIH5xNni/vAsdM0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=hjC8mLXw; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf24.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.166.47 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1705518849; a=rsa-sha256; cv=none; b=Hrr6HAnx6Xnqcht3QQo6PxDIzGviXh0F6uZEHZg5+PuK/W91hhSUNQK9GP8Ug/nhC01FUU Fia2EaMnHEoTpM4cm0EYTCKRwtXUUZBsG2JOykIPaL0zmnUCUw/ADMM8sc6VqDJmNZc3jE FERL4fMykKyK7VfxBkqIS6GlyRCgVDg= Received: by mail-io1-f47.google.com with SMTP id ca18e2360f4ac-7bbec1d1c9dso550647939f.1 for ; Wed, 17 Jan 2024 11:14:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705518848; x=1706123648; 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=2N7+b+9eTmlV+1hqRRxK5amXtgZFPEj9WEU/LCvJugc=; b=hjC8mLXw1+9rgWkm6IUOT//2Ib73wzRjAd1ww74WCIEn8hQQKgluSA7HtBzQtZgZxk p1alW+Biozbj1cFasxA7ERFl12iteY6Lwhb77UcWPeiV7DfNYBiNBYJUia8cQaB/U8Vg GCutMBCYR3RrK7iOh0BLfewdp8pwQ8BIe/6zzV/mw+csfLpg0U746g66RlmO0LQ2mirk Gqga0z+S+FMyVyKKtUcF5QxIp8xKbJW7RY87qYoa65qsZP1cE80ScrZRpoGjc0LP4K/Z fRcT4gh4FGZJKDVRaZCoIh4mOiRppi5UQXL4n5CyHtVWqwQnOCHbr41+Wrjf7tpmEzRw XTUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705518848; x=1706123648; 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=2N7+b+9eTmlV+1hqRRxK5amXtgZFPEj9WEU/LCvJugc=; b=Kv1qX8F+dKW0uSdTjBTzr83F7wMDDuVv/KtVI972sKgcxlDZzfvZuVZjycKqXMn+OU Yi/UFkkjbnTmA9yWbWNAgI72U9ZpGWXLFkDPCqjAANcDbgSa68jUTZ9aLNZTAFN8AxxS s5QSO3nN85GQflWatK/Q1xLJxoPdX/4GJ31g2DhYCOCrxy6oeXkTOyMPHcMzhy95c6YU XTXXenzmb7xV/4aqyx75oidZq2FxHQZv8T8eDCDRfIyGaZR6LDmMWkJ1xt8bZG3lGwmY eIWUYqupR60yfiSqhAyjDPBIayk7yuwr7nuHh3SeAUULvIs0dXMrNMA7i9YK8qxftUrq iCfg== X-Gm-Message-State: AOJu0Yy5YQbnSteLBbs4Xryyic2N2WQFABgj51AiwxfHvwBhYneMl/1e DNNMMyL7mpN40W6OTLhitLbkxi7JQkh4C79OXYg= X-Google-Smtp-Source: AGHT+IH42lhRoe3RkRSLTvfsn0KxrW3p2bPJECxj5UwhVBlSqrKgaSGyCgEg9EaiGlcaWxr1jc5H8HAdoa/R/FK/kqU= X-Received: by 2002:a5e:db03:0:b0:7bf:4f07:716b with SMTP id q3-20020a5edb03000000b007bf4f07716bmr4908995iop.22.1705518848512; Wed, 17 Jan 2024 11:14:08 -0800 (PST) MIME-Version: 1.0 References: <20240116133145.12454-1-debug.penguin32@gmail.com> In-Reply-To: <20240116133145.12454-1-debug.penguin32@gmail.com> From: Nhat Pham Date: Wed, 17 Jan 2024 11:13:57 -0800 Message-ID: Subject: Re: [PATCH] mm/zswap: Improve with alloc_workqueue() call To: Ronald Monthero Cc: sjenning@redhat.com, ddstreet@ieee.org, vitaly.wool@konsulko.com, akpm@linux-foundation.org, chrisl@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Johannes Weiner , Yosry Ahmed Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7E49D180006 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: th8upyub4bdkrdwj4ccrofmw6ai4ay5c X-HE-Tag: 1705518849-504281 X-HE-Meta: U2FsdGVkX19uF98Y2E0oPOcGGsLwa8L2IMgnN1q0/fOB9/RDjkDlGfgXV5TXmvSdXyxVUduHK1ZxPM2i8wnXaiovqla5hau/j9Vi7W9TwLHwZuQKh7E4NFYKPdh5Ol3/RgsSo8OyEnwcyR65PfupfTy4yX8BbDixHzDm+SRNxu+l+YUYc39lgCoyMJHTq0dEoGFHs0+YUpAxglmKwmqUvNzW1wHRqtS5vf6w4qsK5rqRHD6SK7MaRN9FW4UaNWkhCxFtyv7GysL+/LBEoFPl4Fa5K94whkmz4UenpexUBArDXLDs/AEtsAoQ9MemvoQPqh/JgQnzeKtVhUoralOLTW80knOoA12vSYTIKcwyU76rj/YvpTy3dgW53oRG02+H+85uSpjXKZGiH3KQ/01LqZKPd4urElVBM+bHmQAnieBzqvoKJWwU+++4ufV8z8Cw/IX9g0qodkCkf6IfnpHHoyxlQu1lGxmsUOLxYBDxhxidVRD2G0Rrlrq52DBznhOqC0S+VFf4kWIes6COil7pAtYqNH+gGeCYuedrFdteqhn0DpnPutp1jL47z30JLHBJ/vb8ezpeiS41DgYCZ3FwJ7nHmEgQSweahQI3mtlphmoky6xBvgEvqA3QG9YM1fWSQAN6YYEqK7yqDdQHYNEk6JHMk2K0IwM8OH46Hb+GfAIljYtqNw8lkEit3IdyRP/atkm3O2ziTxmHCVUqK4QWo7fZcDjzs8cD0nITc5kO8CmXZjYipo0d4m+4W9rocVX1WXbjwbWnmHrTda8zEfkXHpatGbqoGEDg62xUReZXtayBtMtXexdfWaVvl88nt5kxUO1JaV4vD/2oqILEoyYSfMTEPyZz2qTJ5VvVqLH2gXUJJuBvpYf51sCzn8L8BU/Q/IiuXXWVo/RUw0zr2nIFmz4xMTEP6jcQoDap82Ide2sG18A6KtOqAk6tSFn2rPuVF1jN/PGKLbuE5HRBuGZ dwHaWFQn ILMrPRqImFPiAkdwxWC4qExn+F6cb9N8syyHeiXssY8nQoAsNM7Ej4hWkq67YRgwSraKUOIGf4iaFXBmDxCCMA82nLk0V3SVSM8DiTp7JsSTJ9S8YUhAukp/RJ1FnGLwA2oauCUqCS3yXjJbUoJxSOsO3UMwWl4prRMC0T+FocW2ex2ZAq1B1vbQy7OK48ZQGsO3LMTnEwKWEmttrAc+dJCTCGv3voBdMJ+8rBBVO/pZa0Sb1JxXghkCC8aQkfPutiHdLqKHM26Q0Xsxq7Ii0Dg+WdQ3k8U1AAC1IZt/ns+jzGNvseUvNiyVfKeiqdCM88rGaUrygqarBAhIe2D2cN8OyWPl9LKJyyhsZ1pTk9GznY2rs7ALPfu8PLuOAAqw+hpKZz83fI9bHxrtyQM2ezYdfZg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000222, 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, Jan 16, 2024 at 5:32=E2=80=AFAM Ronald Monthero wrote: + Johannes and Yosry > > The core-api create_workqueue is deprecated, this patch replaces > the create_workqueue with alloc_workqueue. The previous > implementation workqueue of zswap was a bounded workqueue, this > patch uses alloc_workqueue() to create an unbounded workqueue. > The WQ_UNBOUND attribute is desirable making the workqueue > not localized to a specific cpu so that the scheduler is free > to exercise improvisations in any demanding scenarios for > offloading cpu time slices for workqueues. nit: extra space between paragraph would be nice. > For example if any other workqueues of the same primary cpu > had to be served which are WQ_HIGHPRI and WQ_CPU_INTENSIVE. > Also Unbound workqueue happens to be more efficient > in a system during memory pressure scenarios in comparison > to a bounded workqueue. > > shrink_wq =3D alloc_workqueue("zswap-shrink", > WQ_UNBOUND|WQ_MEM_RECLAIM, 1); > > Overall the change suggested in this patch should be > seamless and does not alter the existing behavior, > other than the improvisation to be an unbounded workqueue. > > Signed-off-by: Ronald Monthero > --- > mm/zswap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/mm/zswap.c b/mm/zswap.c > index 74411dfdad92..64dbe3e944a2 100644 > --- a/mm/zswap.c > +++ b/mm/zswap.c > @@ -1620,7 +1620,8 @@ static int zswap_setup(void) > zswap_enabled =3D false; > } > > - shrink_wq =3D create_workqueue("zswap-shrink"); > + shrink_wq =3D alloc_workqueue("zswap-shrink", > + WQ_UNBOUND|WQ_MEM_RECLAIM, 1); Have you benchmarked this to check if there is any regression, just to be safe? With an unbounded workqueue, you're gaining scheduling flexibility at the cost of cache locality. My intuition is that it doesn't matter too much here, but you should probably double check by stress testing - run some workload with a relatively small zswap pool limit (i.e heavy global writeback), and see if there is any difference in performance. > if (!shrink_wq) > goto fallback_fail; > > -- > 2.34.1 > On a different note, I wonder if it would help to perform synchronous reclaim here instead. With our current design, the zswap store failure (due to global limit hit) would leave the incoming page going to swap instead, creating an LRU inversion. Not sure if that's ideal.