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 46693C27C4F for ; Thu, 13 Jun 2024 16:49:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C85496B009A; Thu, 13 Jun 2024 12:49:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0C266B00A5; Thu, 13 Jun 2024 12:49:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A77DB6B00C0; Thu, 13 Jun 2024 12:49:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7FD686B009A for ; Thu, 13 Jun 2024 12:49:20 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 063911A01D6 for ; Thu, 13 Jun 2024 16:49:20 +0000 (UTC) X-FDA: 82226450880.03.678D9C4 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf20.hostedemail.com (Postfix) with ESMTP id 420011C0006 for ; Thu, 13 Jun 2024 16:49:16 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lTDAk4co; spf=pass (imf20.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718297355; 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=wYZqS3WmpZ1OvyFzFMKzzNWnX5VrFLB0li+OWnNc9tk=; b=MbJ4LIl0UxiHmCygSb8HXR/XM8ME4WRsC9BpCNfFraQoaZgtsIUkIK1H6+AtTvLveVCNDL S9dCgnW4xTZH7HZ0Xu4AU5NjlZUXknNyOHGkjtFHqoWWtbVw0jIV8EtwFFB3G9s+uBjX7E Qn9zUYdt1qc1buaJe/kwZXZ+eYgeBwk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718297355; a=rsa-sha256; cv=none; b=L2Ys2H0Mko/2GWLkj/cqdADrxjFiPvPnWg1PCNRXhRny8FytGrPIrUto4wQgkQLvOfbuBN oVl5wvO8mqFgm4Vd0hr4dN6LmzwIqKOq8Wq8aM9O79h5silnpctuUW9YN9Sv3hCWb934Kx WIPe+A2CgdwQUUdFMRD+85XYOTr5ZDI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=lTDAk4co; spf=pass (imf20.hostedemail.com: domain of shakeel.butt@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev X-Envelope-To: nphamcs@gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1718297352; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=wYZqS3WmpZ1OvyFzFMKzzNWnX5VrFLB0li+OWnNc9tk=; b=lTDAk4coW1qoEqSDcrGUh77VX9j2ToBzIDmRD01DGlpZ2pVHQOSkG9HMrZUWcbzW7hp1ia ubqHXDB4O45iH/naEAOAuHIR1o6brS/DizNg2D09vDop/YnP1binzlzb0CGPMvXO1oDW7q t3sjoCaZwpP/bn3Iv10dVkKj4mCo+ik= X-Envelope-To: yosryahmed@google.com X-Envelope-To: flintglass@gmail.com X-Envelope-To: hannes@cmpxchg.org X-Envelope-To: chengming.zhou@linux.dev X-Envelope-To: corbet@lwn.net X-Envelope-To: akpm@linux-foundation.org X-Envelope-To: cerasuolodomenico@gmail.com X-Envelope-To: linux-mm@kvack.org X-Envelope-To: linux-doc@vger.kernel.org X-Envelope-To: linux-kernel@vger.kernel.org Date: Thu, 13 Jun 2024 09:49:06 -0700 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Nhat Pham Cc: Yosry Ahmed , Takero Funaki , Johannes Weiner , Chengming Zhou , Jonathan Corbet , Andrew Morton , Domenico Cerasuolo , linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 1/3] mm: zswap: fix global shrinker memcg iteration Message-ID: References: <20240608155316.451600-1-flintglass@gmail.com> <20240608155316.451600-2-flintglass@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 420011C0006 X-Stat-Signature: bptx996knb17jimdijohtufqwttjkmi1 X-HE-Tag: 1718297356-782926 X-HE-Meta: U2FsdGVkX18tSO2Y4lIeJSPBIqXxumLhA/B3ZjSkw8Kft5jY6RiPtQy2hH8CwEuALC3BkLZTd9PxZNRrlboWyGVGNe7HSSy8i/75rPI4hBgBri6MfxttkBzKlsNw1iNO6p5KW/AQYQ5Yrqk2tGdNVpqjgKs2vUwmPT0ZS5sxOhoOsTJCWYhBIIcOGrUfSWRSydlRDhPYbVaWKF7fa3VGQinzowHk3YgANN0rE6yeRoF65NMG4jJPdb0L4OwezrO52u0pKyQnsaQmFNS5axRG4GISBJ3GOL4CTGpZks+rlQq3Qa2TxV3fRZ7bkeXfC2e/52NJKh6TvUoaKR5sHHwV5HSwjLUlLBfghZg6Vdhj25LI4NDrz4HYF+WPWObnHF/y7I4PljIAvmQjce80mgrIKISPGZjhCb+O1/cAefGnNqLExsahsAlUq5y3vU/JP4txGDcIf/YpCmN+2xuuG4F0H/Nvd+JktOwbVnIa+nAaAaw2ddan0/+KWt4X8uoCP05CoFdQo0td7U+ldoCx5eK82TYBpgcF0ae3ubl4yUjd1WZsxKF/WmkT3PGtp90HLh03FstmKFhX4QLLq3kp1NKFJP4wJB75nfetDtimvstl2Da2qLNOvEW+PTl4yiFa3Cs9UudDbSjTQattzo21loEbCUFpqRehWXG6uqF4ubdAvEiGYG1/tXMSJ0uOTdHDbgmyt1hFAyi3dKWo/gqnZsIiHqXmFWC8nUp6lmT1njtP2w6J935Ze53o1awlY/Lf6Mhn4lzwWGhNpOQQeS2ffvR9erxKIl4rCXJMX+XyJ1HSleCAxQgfXMzQhwR+ef6UaculGBmzE32+rTL49C2zVDnEbnjGga3ljV4QWxn8vHYZVNg3Pg4kJma3/MK1DC8rgM5ifl7Ke2xT22VDuaNiW1fytl7rTiecOR0Ix7sMWRDSREtFzAqU+xWaGdGRFFxFm6wHdSdMUaE9DlF6N4/smt2 QggmJIKn 4wUFBa7zvrzhEXmoWz+rxscgX2G9ZBF3SM+h97sPoTnWBZUS/S77pZL+zEz62zalqvPgGstnGMkozNGk3bmlYURJ4IEkrL45AlXkdqGwn+NcydGqYdbYvMWop90Z0+Z1b8CkU0qcR8d3PXY8cE4CSR9Pa41yYvhjjSO0HR4IGH/axKdo2I5Ho4ynWjVvhAkh9PT14756h5PCn2kU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, 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 Thu, Jun 13, 2024 at 08:04:39AM GMT, Nhat Pham wrote: [...] > > > > > > > > Is the idea here to avoid moving the iterator to another offline memcg > > > > that zswap_memcg_offline_cleanup() was already called for, to avoid > > > > holding a ref on that memcg until the next run of zswap shrinking? > > > > > > > > If yes, I think it's probably worth doing. But why do we need to > > > > release and reacquire the lock in the loop above? > > > > > > Yes, the existing cleaner might leave the offline, already-cleaned memcg. > > > > > > The reacquiring lock is to not loop inside the critical section. > > > In shrink_worker of v0 patch, the loop was restarted on offline memcg > > > without releasing the lock. Nhat pointed out that we should drop the > > > lock after every mem_cgroup_iter() call. v1 was changed to reacquire > > > once per iteration like the cleaner code above. > > > > I am not sure how often we'll run into a situation where we'll be > > holding the lock for too long tbh. It should be unlikely to keep > > encountering offline memcgs for a long time. > > > > Nhat, do you think this could cause a problem in practice? > > I don't remember prescribing anything to be honest :) I think I was > just asking why can't we just drop the lock, then "continue;". This is > mostly for simplicity's sake. > > https://lore.kernel.org/linux-mm/CAKEwX=MwrRc43iM2050v5u-TPUK4Yn+a4G7+h6ieKhpQ7WtQ=A@mail.gmail.com/ > > But I think as Takero pointed out, it would still skip over the memcg > that was (concurrently) updated to zswap_next_shrink by the memcg > offline callback. What's the issue with keep traversing until an online memcg is found? Something like the following: spin_lock(&zswap_shrink_lock); do { zswap_next_shrink = mem_cgroup_iter(NULL, zswap_next_shrink, NULL); } while (zswap_next_shrink && !mem_cgroup_online(zswap_next_shrink)); if (!zswap_next_shrink) zswap_next_shrink = mem_cgroup_iter(NULL, NULL, NULL); .... Is the concern that there can a lot of offlined memcgs which may cause need resched warnings?