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 6EF22C54E67 for ; Tue, 26 Mar 2024 21:49:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CA9E06B0085; Tue, 26 Mar 2024 17:49:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C59CD6B0087; Tue, 26 Mar 2024 17:49:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AFA9E6B0088; Tue, 26 Mar 2024 17:49:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A12156B0085 for ; Tue, 26 Mar 2024 17:49:44 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3374314016B for ; Tue, 26 Mar 2024 21:49:44 +0000 (UTC) X-FDA: 81940532688.07.6FD72A4 Received: from mail-qk1-f170.google.com (mail-qk1-f170.google.com [209.85.222.170]) by imf14.hostedemail.com (Postfix) with ESMTP id 70FEA10000F for ; Tue, 26 Mar 2024 21:49:42 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Zv8TSsPN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.170 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=1711489782; 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=ZEGnANGCVnpDGUZcTQwIUkqQ/IKd//G8yebAW3mMqzk=; b=tPoy9sV84+6lCTkPYAdPKPsk/jFvwBj94+l0bIcVt3RxkEJ54+Ta+FPoBoxOWi8C49lnlv 3XJ/B9zbcXQpVJHLHic8w+QHEtLvkLCGaEwfkopUqh3UPth8JNROIim+mqFTS7iOffWIhL Ivk0QPy6ZtFvSVAyLGa5vwe7APHAvcA= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Zv8TSsPN; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf14.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.222.170 as permitted sender) smtp.mailfrom=nphamcs@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1711489782; a=rsa-sha256; cv=none; b=gPa9g1S9nQ8F9XcwGBYHTbfJz/lxA3JAwDWGBAMts3eRupwrbdN7cD3knLaJGuWYb9vku5 Gpw9jUnVD7lLY8LGtGq5VPCghFD/6qTXPfnh70LRATwOEGEuiVxiOR63S5BU42JqqYk0Gz JoAhCmh/pZ0N2F2jUHk4DEYAJSA4SyM= Received: by mail-qk1-f170.google.com with SMTP id af79cd13be357-78a3ca01301so274050085a.1 for ; Tue, 26 Mar 2024 14:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711489781; x=1712094581; 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=ZEGnANGCVnpDGUZcTQwIUkqQ/IKd//G8yebAW3mMqzk=; b=Zv8TSsPNa+jyqSvFPTl4wYsfbZvDp1YV2lnMe9ouirIFZcb/h5mepZ2xg5ZiuSD7sw gwvJKf4V7QaVZieVZskUUcAv6MKrn7HsiEtDYZce/8C2l37v1FSnbc7pnWNNb3IKPswi rnKLm8n3k52TymZo7vN8IE/2NoYilcyMLiYwZJxqZFTGoWg+t0OCjFjN4p+bFKnYgKYo wXcvbagtnyg+2F+4ytnp9w7uksCGdgXLvpVREC1QES9Q+7cZ09YHD0wiBGeJpW8Ikqy0 Y0udDOjJiXdMuQd5mQr3r1xIyuTFCoirbYCit/zMaLiBD9VVE94BMF1RpeIGZ7tHHHKF 9+yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711489781; x=1712094581; 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=ZEGnANGCVnpDGUZcTQwIUkqQ/IKd//G8yebAW3mMqzk=; b=lO2meMEdmAuqakyqKIxZSxVWKRhFmTfk/RmPpkdwPlL9cUWe94h62l7hoJ+mZcHL5B FOttIAvwGtDs8w92PtfeH/uTCUPlKKwEdxVcxbfIkzwZsWHjfrC052mX4S3OtYmBoOmb jwjwPVOU1xDERlZ9+kg6IdQXsPMDEXQw/vb3me3RpDnEnSEggvA9rK2OUitDovHpfSRX Rs87doOI4w60CxxAbV1lB9+sh1Xtkl15a7OQJFQtn6j53NnvRcMk8xxmgX0tiPuDLgyv z/408vkdmZkskeACrN3FywSAwozQZ5iSN4yLtxaFD4KRKY455OgPDpzND3jUa/jNEZ6o Q1WQ== X-Forwarded-Encrypted: i=1; AJvYcCWTWloFPudxkkk7sqkG/ocSt7JNLRFlOzeWFhHVP+hIy8Plnmt9VvTSbkGgspQyTE8E+SAe/861aKjfRt/hztnGQMI= X-Gm-Message-State: AOJu0YxAGdZHZs05VYzvRxhJVOQpQvu9tEMeH5AauT9EYdSjp4qbVSV4 pHwWar6dndN7lEL27qkVgBoz/qLG7+BB8pMJ9UjVxjwSBpl1wvKf2/owIRlMeUlcSxC5fkUcZOp SSLD12nCUEyr4a5c1nCUnELZ1YH0= X-Google-Smtp-Source: AGHT+IGZRfsZKvzxxmjKHJcU8npENvv6KZIBvRhpv0stws6LsEWKrN5MKxFXWH/RhYDtrr/SPkvIL9YRckODznyn6Us= X-Received: by 2002:a05:6214:1cc1:b0:695:f40f:d7e6 with SMTP id g1-20020a0562141cc100b00695f40fd7e6mr728029qvd.28.1711489781475; Tue, 26 Mar 2024 14:49:41 -0700 (PDT) MIME-Version: 1.0 References: <20240325235018.2028408-1-yosryahmed@google.com> <20240325235018.2028408-2-yosryahmed@google.com> In-Reply-To: <20240325235018.2028408-2-yosryahmed@google.com> From: Nhat Pham Date: Tue, 26 Mar 2024 14:49:30 -0700 Message-ID: Subject: Re: [RFC PATCH 1/9] mm: zswap: always shrink in zswap_store() if zswap_pool_reached_full To: Yosry Ahmed Cc: Andrew Morton , Johannes Weiner , Chengming Zhou , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 70FEA10000F X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 77xrq6s99f1z7psfr6eaf8juaezpb35h X-HE-Tag: 1711489782-956848 X-HE-Meta: U2FsdGVkX18QvERoEOdnxXQNp0VO2FDc5Oux1O4sNCwdGS+TvNGZCUP4pydSCC4Qpryykv13ciSMPu7I+443h370ICHwO3nRvmDDuPgoQMU1VUsCR5Z23oCwRoSUD/Y6+sQKFdslpGUnwXRopyl0Pt+glKD9ou3ta4qBLD1PSp3a2ded8gFHE5XrqY8+RGMJE3/yqqABBvXJC4ZI/9Ds1mShBraH2IL/yWP2re+L8Q5qwOPE+DimdHV/uQ73U7L4/6OFXkRBIFGbAt/3EJ5RmnXRDErqnfUCn6aRIvLKOTPxPcc8vYxxhoUnIF8a1mvlCUkttCsyS0AnYlSR1kfl9XWWi3vNa7nEEpgmZ1A+fkAsYzjImfFjQoAiavfStZ0eJ4DUmbAHnwGYS6KLgyiRLpilfXEHEe/Gp4hqGZJDndbPtYMyv8q/mElZPpIh2gTQ6OQzyCcPKug6lWJ6nY+lyrswmkMBFh2P7q/m5fFXggt6ZZj3cNmMvBkEgbDFvt9hDVMZBD1Gkz1EgQG9q8QnL0lvDbw7ERp/te9NVBsL+UaGOveUhZEZQUGpDduAJGSPo6Y90CT+9gcOYasOCj08Bt3qwSCyA32QAVuK+dd+pntYUO2UY8zz8E6fDFECkmKC5Z5QrGm+dIHQLi1HF3gdG1DNkM4FODrEnCcAPAqpEEl53fnZxMLEwSTX53t1vfK3IQuXLwMBIFQry0D5XPtFvK05NSjpL0PPjT3lh9D5YzRHOlzCxnJX3L6npGrPsjbf+zVUJrLWLOqoKnUEV6wXMddd0YOKPEirXnOfiTkXCgvr6ckjv7fj+azG7nYYhKDsNSCMjxDyO4iZcxp75yWVibAHVWqbns/9xLakGzWpcsk7TF2BBMlnXlBecVQ8ziPpr0OHeVeDT/TGxziwz0DocUlCtGj4ZxY27907uxRvli22QqB0O26NJTDzSqAC3KtaEUo8AG+uj5gjJf/iVxx 7AWlTixv t37fN0QOFB45nu5o2fm0oNrcByubk8jJXOpXeACW06eZ83jw52ZFV7Qxld4Tc59fuxCGZ1bJFPs1bbi1i2ipIs9378/6tthTmzENaM7VrEP9xBPid9WNqEg50UULp1RxDZmEgAiSlYieP97ZHw/iqUmw+DB+O+bjw1JNCqBGLfHEfQbMPUBm77vOpCkSNBCuQtorsptHA9WzZkFfmN54daXe4o35xbRPDUYus1YHcmDAmG8229xtRyykCq3WxWkWFdFqWd6ScKoL68yR2xzN90GtsroDQeAvo7fyYIm9w3oo/jaAC3FE1kuMIV3qFLDvteRkA5wEsFOL6R2E38qK99Uge0JLYvnPWLj0zDp9EiWdsgMEVbmguSgPWGu3j2F2yCUw7mIL0rxJwRMDvWCdh8UI2rr8PMK+VVavPm/OZualar3xeNrSeYsQbVESVDG22rj+8 X-Bogosity: Ham, tests=bogofilter, spamicity=0.103746, 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, Mar 25, 2024 at 4:50=E2=80=AFPM Yosry Ahmed = wrote: > > The cleanup code in zswap_store() is not pretty, particularly the > 'shrink' label at the bottom that ends up jumping between cleanup > labels. > > Instead of having a dedicated label to shrink the pool, just use > zswap_pool_reached_full directly to figure out if the pool needs > shrinking. zswap_pool_reached_full should be true if and only if the > pool needs shrinking. > > The only caveat is that the value of zswap_pool_reached_full may be > changed by concurrent zswap_store() calls between checking the limit and > testing zswap_pool_reached_full in the cleanup code. This is fine > because: > - If zswap_pool_reached_full was true during limit checking then became > false during the cleanup code, then someone else already took care of > shrinking the pool and there is no need to queue the worker. That > would be a good change. Yup. > - If zswap_pool_reached_full was false during limit checking then became > true during the cleanup code, then someone else hit the limit > meanwhile. In this case, both threads will try to queue the worker, > but it never gets queued more than once anyway. Also, calling > queue_work() multiple times when the limit is hit could already happen > today, so this isn't a significant change in any way. Agree. > > Signed-off-by: Yosry Ahmed This change by itself seems fine to me. Reviewed-by: Nhat Pham