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 4B1A6CA0EC8 for ; Thu, 29 Aug 2024 23:45:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BF56D6B008A; Thu, 29 Aug 2024 19:45:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BA6596B0092; Thu, 29 Aug 2024 19:45:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A94116B0093; Thu, 29 Aug 2024 19:45:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 852E46B008A for ; Thu, 29 Aug 2024 19:45:45 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 26379AABF4 for ; Thu, 29 Aug 2024 23:45:45 +0000 (UTC) X-FDA: 82506917850.10.B55CBEF Received: from mail-qv1-f41.google.com (mail-qv1-f41.google.com [209.85.219.41]) by imf17.hostedemail.com (Postfix) with ESMTP id 56A2C40015 for ; Thu, 29 Aug 2024 23:45:43 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XxXKkMl+; spf=pass (imf17.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.41 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724975122; 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=PznsqK0p6k0E9T87D686uSgXj4y2tO8F5II7uB0+Rwk=; b=JypENSulbBzu+2mi0+xWPAbiF8XC+Kf0GpTSUslP116yPOkG90OYnl7b9y/2mzgrxnOVac xM2r20xWX0+fS9LBtNXbTN2YUXPdnuk0aufrxD3hcrU9d9iNaiGvXjXCs8kzqwp/jwO0hO TSFjwPAn7LEBU5WQVN13dTtqmTi4B2Y= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=XxXKkMl+; spf=pass (imf17.hostedemail.com: domain of nphamcs@gmail.com designates 209.85.219.41 as permitted sender) smtp.mailfrom=nphamcs@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724975122; a=rsa-sha256; cv=none; b=1SaASJAjgFadpFK9Hi1lTA7ERiWyH1MaEmWaGEJjGtju+sZQhZtG1rS7B4mVCuf8iXMikT L9khBfi3vX45aq9C2w+X9SXZehyYkhQJn+Wk5YVXTEwW0PeHEj7e/OkPpcNdfAW5DYV+E7 wLD9Xi3iWlMl9jCYPg1TFpFvXgSHtgQ= Received: by mail-qv1-f41.google.com with SMTP id 6a1803df08f44-6c331543ef0so7018366d6.1 for ; Thu, 29 Aug 2024 16:45:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724975142; x=1725579942; 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=PznsqK0p6k0E9T87D686uSgXj4y2tO8F5II7uB0+Rwk=; b=XxXKkMl+PC+nnhYPw/F9krtnZKNowpnIFmTqL6YyvyIWKDcxc1KcMq3CyBwrXT7l2C sswL+O+w1/vDa2wnELSQW74SH2PXcbCRIMcW7sipkpwT1JsnfTrmrXBtAXUvfwkiMI8h Ol2eRDQ/n+zbV2wFbRFoCEWnCyZGv6FYwiHWThf/UMgA2IR/EoAFZdfNLKlNwAfQEEjz CyIDhxiMJ3w4b1OmPCClB4Em+NFfDMn9SEJ77tUVKFPmUu/oh4Es7HOFG3Dg0EqRntcu sbeo/c/6lr09oFB+Sm7v827tiKQuy4C5XcIbcEDlxKWzRAYbAEkLYA7ZcTwHvcoezBS5 H17w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724975142; x=1725579942; 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=PznsqK0p6k0E9T87D686uSgXj4y2tO8F5II7uB0+Rwk=; b=RouT9DxYhrRNBPPsE8UABvmF/GSONoReYRUCF9R8732bY0oNo6N0fGRfeHAmEuHBW6 c5Mn5wZexJoLjr5FnyuHBpcCZkodFZAX5FLALIVSwjOfbo22KjNquU+OO1+uD30Ej/40 bMYLH7Yc8N0aRJKgjZsxoxHQTRx8UlzpCM4eDnqG0mizB5TRWPFbS261imqMvuWuH0dX rizDv27EKJDDjxk0gOlNP+5+ozaAjWG6tCRUNfdKlVeyYPDG/opxjBygXO1MQu1TOdPN HwGUISXFoJL+aKzGfnIQQY+nXcw27cfTksAtEXMxABmaBbBSmwWV7O/GeIbrC4vu8rmG xsaw== X-Forwarded-Encrypted: i=1; AJvYcCVgXZMpkSLevFfMOQ1feAgHUKPi0whKRyzlukMCwn7OOUjL2ePeg3pC/60KrjuhHoKJClkuR8kQqg==@kvack.org X-Gm-Message-State: AOJu0YwKxJA37TPLy2+CFLy4phaOmIuPr5JUe//z1DvbL+kahulE4VFr +9QCgwU83AVcEMMg3BfehZ/wzVX5ZOZkzI02XNxsBMSINAQrSJ28Rh+saTX+EjVH0eVcoLaHlvk DhviejFWisTq6y3GUhQSroX/+L1Y= X-Google-Smtp-Source: AGHT+IFu4hzc4hructb8wMHMMH2MKWxDpe3dxSJQpYCx2L/8g+RhM5u2t+dJK33KK+SYcJHvhTEPKtWgyZz1j+j742s= X-Received: by 2002:a05:6214:419b:b0:6c1:6a71:9439 with SMTP id 6a1803df08f44-6c33e4f9d92mr46393036d6.0.1724975142225; Thu, 29 Aug 2024 16:45:42 -0700 (PDT) MIME-Version: 1.0 References: <20240829212705.6714-1-kanchana.p.sridhar@intel.com> In-Reply-To: From: Nhat Pham Date: Thu, 29 Aug 2024 16:45:31 -0700 Message-ID: Subject: Re: [PATCH v6 0/3] mm: ZSWAP swap-out of mTHP folios To: Yosry Ahmed 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-Rspam-User: X-Stat-Signature: 96d4rm5yye7hpohtgscc1tb8na8f7ixi X-Rspamd-Queue-Id: 56A2C40015 X-Rspamd-Server: rspam11 X-HE-Tag: 1724975143-636730 X-HE-Meta: U2FsdGVkX1+WHWx9XUwY536p+G+ChBFzvqsYm9Ur6Pf0h5WSUFj081rGVQJwSamgH8Lvgyu58PcofVNy27MaceH4oTGedNXHtbxBnAD3a8B5i8M+8X72iskAKkdUTBwC1vBNM0Wmr4WcV4ZhZRjQh0GlAElv4wh3zvD4KtKs72010G8nKyIVJ4koV1s5k3noFxb2Ql7TNZgaGLptP7b/2oG5SjkPoLsXu9cX8Y9WxQAMPyljluO35c4W56Ki1+BMT1AdzGBJYwl3TNyOmqpvdD0Kek+uCeoP1LK9VqjZuSI8aZkSt3ZTrP9RcGFc/19AZhSKkUyyD0eD055GIJ2146Lg5V1xvdJrIfXDQCfcy1o6YUEsNzYiOT2V0u6MrI0R1VP/JN4O/32FSV8MeG7A1x3W22XjFL1FKES1igh3dF/aUAz2+Cp5AFYZ+td5Wfl7MBSGgCiVJTP7PI34ICaHOOo2a6pgVKltDjIE71ijrN651oQA6cvZcLXU7NE0wolrhgVwT99ukibxA2ZoUnHHfe5hsYBzY41t4c3/dkz5gQiPdI8yVmL+k9h+oCh3OOqzoPH7RZyeVuZxOWoj4XMT0e5g57ZiChqzUSPTrpZbVON5KfVli7Z3LkUqQycrMiRN4Xiz7M6CDH6a/EhTtykmjRAt3Hv0F11pqfxzF60Tz4YOBJMDWFZ8T40Q5Hkl5rrRY5Rft7wPdhCIhsi85+5olf/sO3EqiZIMrBkrBZE0WAn0Ag2sF4AOL9o+N5ujOMB/mE/RrBqUrsDYJAjB2PxRo6TCH58wFdoHU/hcU98sZxfc+1YX4AAaxXkPAoTDNW0px06/KX05700JCbKkYtu+svH6o1zykSYXpVnIx9heR+/EwB8I6+ArG+9p0aOf69o1nlB3Y3sjIZhXmVXkNArw7UFG7EliD/hWbmTBKWlDduF/aTwVOeGrmcDwS4kejCItj/AqVP74CgR5BUme3vT cvkZRRT+ Vz6cSeQNk5z0QXHnw0Jk53g1LoPE/xaMFoz0CKhcmGASENIAz8EpCPQWspWNHFzjH2DQ5sOKNLoz3E/8nO9eBzL/ERxhvj9rinaLucSwx994Z9wtuTRQaorUQAfO+wF4fyvmt4hD6Q/wnK3MmQO9v5sLN7VLz5LiHSvPBQyGXG116P/J9Ih4OkXE/pxY22JuvUuGXLJban5bXucYM9xUkx8NJsexV6lJm0LxPgwiQqec7yZir371wD5GIv7rhcPGoDige+MM9flw4FOLKzKkF+xCWGzmO4Zd+q8szqOK/X5vfGLAOGjkFwzyVB/deUfGggBA4YY4T6C4qoogzNAK5u8IXHQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.013293, 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 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). 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? :) > > If we really want to compare CONFIG_THP_SWAP on before and after, it > should be with SSD because that's a more conventional setup. In this > case the users that have CONFIG_THP_SWAP=3Dy only experience the > benefits of zswap with this series. You mentioned experimenting with > usemem to keep the memory allocated longer so that you're able to have > a fair test with the small SSD swap setup. Did that work? > > I am hoping Nhat or Johannes would shed some light on whether they > usually have CONFIG_THP_SWAP enabled or not with zswap. I am trying to > figure out if any reasonable setups enable CONFIG_THP_SWAP with zswap. > Otherwise the testing results from case 1 should be sufficient. > > > > > In my opinion, even though the test set up does not provide an accurate > > way for a direct before/after comparison (because of zswap usage being > > counted in cgroup, hence towards the memory.high), it still seems > > reasonable for zswap_store to support (m)THP, so that further performan= ce > > improvements can be implemented. > > This is only referring to the results of case 2, right? > > Honestly, I wouldn't want to merge mTHP swapout support on its own > just because it enables further performance improvements without > having actual patches for them. But I don't think this captures the > results accurately as it dismisses case 1 results (which I think are > more reasonable). > > Thnaks