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 AB329CA0EC8 for ; Thu, 29 Aug 2024 23:55:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 060AA6B0093; Thu, 29 Aug 2024 19:55:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 010D46B0095; Thu, 29 Aug 2024 19:55:33 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E1B316B0096; Thu, 29 Aug 2024 19:55:33 -0400 (EDT) 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 C2E7C6B0093 for ; Thu, 29 Aug 2024 19:55:33 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 29A881609ED for ; Thu, 29 Aug 2024 23:55:33 +0000 (UTC) X-FDA: 82506942546.28.32063D8 Received: from mail-ej1-f50.google.com (mail-ej1-f50.google.com [209.85.218.50]) by imf02.hostedemail.com (Postfix) with ESMTP id 54D7A80012 for ; Thu, 29 Aug 2024 23:55:31 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A2bGTdru; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724975686; a=rsa-sha256; cv=none; b=5OrQIPdCn3onbN00TtLO/bvPHSUxf0lJgBuEBtXCYMRd8rkFeRwLffvXnGo/VdwS4E3jbH saxmFWETyH+pWtP8ny0RFgC20EkS5h9vRQmzYLuwwYFIruaT/cB9gIKtO3xXaYRz7/yISW UV4PISb5H3sUfgh9XdyuEfFgtmWaB0M= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=A2bGTdru; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.50 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724975686; 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=sdAvHc83bX/ecNjmq9gi7vYmOYomwU4OlkBorgJXCks=; b=KWpXzfUXOHLqiavcMHbUVEHWvNWiCF6VY8tZLtWi/n5G8zgOayH4H849+2UGCYPCZlNcv7 E3lYJ3IgQ+JBAWUKUcZYE8ienHukPdSIVrdI/jAdtw5y6E5Ig2R438iSDtImu0yZPCOIO9 lZBaoxx/gIvnS+miMCKuotP3wGtIb80= Received: by mail-ej1-f50.google.com with SMTP id a640c23a62f3a-a7a81bd549eso128185466b.3 for ; Thu, 29 Aug 2024 16:55:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724975730; x=1725580530; 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=sdAvHc83bX/ecNjmq9gi7vYmOYomwU4OlkBorgJXCks=; b=A2bGTdru8eL0SUrSsE/nQT+6q1ZDDGwwR+2ck8U6SOGNa8ZqR7Im2rJkj1Kj5f9yg6 MVOzuhG+qhIhRy79BTq2MPphJrBoYDYSpXmW85r2IPCvoFWj28Smn9eQqie+HDI/moBd ZAqzNC3ON/8q6H82guabPzk9Iy3b5x1uWNQfU+fGKW9k7d6ihBGfaphL6Xay7bPEnnZz n7Fs/FQpJGBnx4r/Ark0oa0OpDs6x03TQ2/ao7fx4yvZLJkxhSJjEqtMLhFz0XTJ9lmk a1JZHfAvqxQgNnL0Ejds8Gzb7++sgA1GgjfcaWcu8+DXAo3vzV6R6Su441I2YU2tz5MB rzOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724975730; x=1725580530; 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=sdAvHc83bX/ecNjmq9gi7vYmOYomwU4OlkBorgJXCks=; b=JLCtDZkqzo3ip6OTDYmzouTFfEH/N5w3nBGLpY5a3BvIJmzC1sZU7cC3Nn0Km2Ak0S rpxw3A3HlVQ3HHvmy7x96ulrwubyDmq8ysoJmFYrfiHLNkSYwjEPhJvsIKu5BH3qKoH3 nuM4ZhxkfQWKnpNDnY2gzbTJFZVsVzyi3Z756Qto/zOoKzdxlt+gMmQQZsndm52MOJCt jgWswhWe150qhAtGaJ6qh+0ilEpvCC3pA0YZtU4vAO5Ii4Js2unhaJZZcc0FEy23wFJ2 4qVr7f9XKZzq6jyxGtmnDXV1gXn9tO3pgiSdK6pRjqSG8vJZ4C70d/xExJhCexqcAQ4/ 1OTw== X-Forwarded-Encrypted: i=1; AJvYcCXYonlPZTEETKKxLVm/6EPsIEWiJlwN63N1AkkaLE3ON4s6h559CoOaOu9lTqos7pKdMkzlXrby8g==@kvack.org X-Gm-Message-State: AOJu0YyTnPPJBuDYqg63xsDCT/C42Tx1sDtCfIk8UNRZGw/Yx6cc0Ef0 K6SC4Ul3xfZW63S5Wo5lRXSPA/6RxHU4r3tubODqkPoREf0jqWdZM0aWDI7DQuYLuO3ub61T/k1 uWezKKFhmg/bSXjj3MQ20IAZFodE54G08QOiB X-Google-Smtp-Source: AGHT+IENa/McnSHCBU5bHgcdBBrsnWg/0vBXZsFH1k7w/8v7wrjS9aP1kCpbK58pID2mp/I9T4JoqKyeZ8/xsKvl17k= X-Received: by 2002:a17:907:9717:b0:a86:7ddf:2909 with SMTP id a640c23a62f3a-a897f7894e5mr309081766b.14.1724975729054; Thu, 29 Aug 2024 16:55:29 -0700 (PDT) MIME-Version: 1.0 References: <20240829212705.6714-1-kanchana.p.sridhar@intel.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 29 Aug 2024 16:54:53 -0700 Message-ID: Subject: Re: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios To: Nhat Pham Cc: Kanchana P Sridhar , linux-kernel@vger.kernel.org, linux-mm@kvack.org, hannes@cmpxchg.org, chengming.zhou@linux.dev, usamaarif642@gmail.com, ryan.roberts@arm.com, ying.huang@intel.com, 21cnbao@gmail.com, akpm@linux-foundation.org, nanhai.zou@intel.com, wajdi.k.feghali@intel.com, vinodh.gopal@intel.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: tbpn3et6k7eiqraq7hmei7gwsg6t7uc9 X-Rspamd-Queue-Id: 54D7A80012 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1724975731-319017 X-HE-Meta: U2FsdGVkX19CsYrosADdMDBeCiXPV8IFQhX7+pVYX2wqtywutuEbpNUPN+NwwfQe5Fdhvvl68emAktz8v/CnZ6k75pD8IMAMPZLdAZTq4FBdbx/hDtCJR01iAKqSskl+6oBmzjDsE7UhT9vq4ypMSFj/7HCGf7gI4Dr93iRBO58HuMyCdzxyEHuAxz0g8C2BtABs4DizNz16bcydZSnYuHtzvOTjnqRj7EVmEy2ymXid466jWXKn43j1Y0A9wBIbTHjK5X7u7Snwz8rq1sAqv3DLzKrL42zOi3xfbzrPgJ5ymoawpQeGbONtkK2E8Fj/2hjYhtV+HL6Sbf0nRfK8AKdUuGYouqbcbVOHebpOwBRm5qAFfY9adrgF/onWk/VZ72/+H1Q5pnwiNKVIm8Pe95UWeRxd/fQj0Nfqt7wEd53mwVKmI8ujQ2NYy7u+n4C9g0fcFPVsdGEySXiKaPSeKnasF8xsawOB7dbOhJbyoUFn1HB2EzrcEW00jXQXctXvHy1nHCWD7ll6hcFoqwj6Y3c6dO3we8FV5sBIDfzozy35xdU7+S18QcXPp3hnsCyAnuUaeJu8EVL7n1bGddxPeyWbgPD3MaL/GPKzegVmLuqacuIhRdPdzz5VTH8bs+WU72IKjETMo5ph2L+bp36zDBQIeNqp3qRsBLzXJjp//Vun+FHsxxNkaN3Rq/AahfrYbaSiI/39KgG2Phq+LB/meWfIqUcv+AFopMB1c/ySR/NAmO4DVq787CPxNFd3tWv6tV3nykXLbrgLBVX8kWgeoTSbtABmJ6f95+HSYrbMfp/+MX/EQLIfspi5DciQjI2ilgxYJzuIOtDhieN7uUmFsAwgcSGjdtYaYxJAVR80Dl8cAvhakFOLKQA4HcaXp6IXOaesSZrnClYmQ+k7TCyavD+aUJ9t2eG4QjZ2j2JkbBUUgpRtKVud7sXfuarN74jCRe29idaIabQmovPckT4 rsxqKbzz 9qZ9uO99Fwt6LNO+34lleKS8X2eQoKEdqpI479Mfd6XjVgSYTVOf+PHXqph4VTYjyHdpKxcPKoqrw0T5F6zuDLjsnmSyiXydmOItOzhM0A6R48sjj2UvbSlhvQFAWsBEHhPYVeSa3LZLu31/FoJLxsF09uI7FT3t+mdZdO2sNirsmJdwI6bzdOH5xpHdBJinkYeRBEV9zs3Hib9KV5FjkuEF3WpmRd/fuJ58cdil1kszsf/8A8NSLzwJXJA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.043675, 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, Aug 29, 2024 at 4:45=E2=80=AFPM Nhat Pham wrote= : > > On Thu, Aug 29, 2024 at 3:49=E2=80=AFPM Yosry Ahmed wrote: > > > > On Thu, Aug 29, 2024 at 2:27=E2=80=AFPM Kanchana P Sridhar > > > > We are basically comparing zram with zswap in this case, and it's not > > fair because, as you mentioned, the zswap compressed data is being > > accounted for while the zram compressed data isn't. I am not really > > sure how valuable these test results are. Even if we remove the cgroup > > accounting from zswap, we won't see an improvement, we should expect a > > similar performance to zram. > > > > I think the test results that are really valuable are case 1, where > > zswap users are currently disabling CONFIG_THP_SWAP, and get to enable > > it after this series. > > Ah, this is a good point. > > I think the point of comparing mTHP zswap v.s mTHP (SSD)swap is more > of a sanity check. IOW, if mTHP swap outperforms mTHP zswap, then > something is wrong (otherwise why would enable zswap - might as well > just use swap, since SSD swap with mTHP >>> zswap with mTHP >>> zswap > without mTHP). Yeah, good point, but as you mention below.. > > That said, I don't think this benchmark can show it anyway. The access > pattern here is such that all the allocated memories are really cold, > so swap to disk (or to zram, which does not account memory usage > towards cgroup) is better by definition... And Kanchana does not seem > to have access to setup with larger SSD swapfiles? :) I think it's also the fact that the processes exit right after they are done allocating the memory. So I think in the case of SSD, when we stall waiting for IO some processes get to exit and free up memory, so we need to do less swapping out in general because the processes are more serialized. With zswap, all processes try to access memory at the same time so the required amount of memory at any given point is higher, leading to more thrashing. I suggested keeping the memory allocated for a long time to even the playing field, or we can make the processes keep looping and accessing the memory (or part of it) for a while. That being said, I think this may be a signal that the memory.high throttling is not performing as expected in the zswap case. Not sure tbh, but I don't think SSD swap should perform better than zswap in that case.