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 2F63FC87FCB for ; Fri, 30 Aug 2024 00:14:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB4696B0082; Thu, 29 Aug 2024 20:14:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B63FB6B0085; Thu, 29 Aug 2024 20:14:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A2C7C6B0088; Thu, 29 Aug 2024 20:14:56 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 856976B0082 for ; Thu, 29 Aug 2024 20:14:56 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2F04E1C61BF for ; Fri, 30 Aug 2024 00:14:56 +0000 (UTC) X-FDA: 82506991392.04.E9C72D4 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf29.hostedemail.com (Postfix) with ESMTP id 5CE1F120009 for ; Fri, 30 Aug 2024 00:14:54 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dGlvUgzP; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.41 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=1724976823; 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=R7Nb/imqwjRvNHvXv+72s2YMbv5nBhWUPovMyoDLXeE=; b=5HLEtNRQW3zu9GvsSEpwOMD8Ygjo85sbzmDRCRPokv5kYwK+1B7JsEqgHSjwJ6B8qGz8BS AlsjR03sKF31CBcTvbUtrH6W/Htujel1JEIWQboBx1QlRdqadrMgc9jits2BN9MRGJmmE0 FJ0E9yttFMK9RJboPNbrcXbkylMMOe8= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=dGlvUgzP; spf=pass (imf29.hostedemail.com: domain of yosryahmed@google.com designates 209.85.167.41 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=1724976823; a=rsa-sha256; cv=none; b=ckYABxbai2OGcCufbvPXUqFuGJaJ4kKU8wDuY2zTFkLt3yowRpX4HgdIE+IwpJAh75B4nq TxQRBjkyOocIqaG7FRQowbiwqR8JN0Kl/z5pv3Ol/PtIM7hqAy+7PN47Y1Lz7c7EU4l3h9 nhqB5jTuXiAzsZCOdhjNeXRKFe3DTcU= Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-533488ffaddso1618043e87.1 for ; Thu, 29 Aug 2024 17:14:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1724976892; x=1725581692; 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=R7Nb/imqwjRvNHvXv+72s2YMbv5nBhWUPovMyoDLXeE=; b=dGlvUgzPSQNrydgOR5p1akKMCmXYS+NcMDPncv0UYKMYCkMgQTE1WL6aVmIWH5Wr6N BB7UJP9M66+Nu+qPNR9TxNpn1gMK9Cph+m9TTAo/VkomNOemfNxzLqaBWy8GGOBXSTVE Pv1C2q438UoLAQRswHH5OGRM+/qOaKp1AssI7ATaFuucE/34rdO94Mly6NFcrGPy9k+o M6TWOdDt3tkxu3r4I00y9MtZvLn8P6BxkDL24eQECkHLNZqaYNLm3e/9sCqCDgYnkdfY AEWgYN2aIzSqD1CMd99X+XwXhbBjDHH2OUC4rZfcir5Oq6ahK9PfxWCYRPr1meJTsliq TcdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724976892; x=1725581692; 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=R7Nb/imqwjRvNHvXv+72s2YMbv5nBhWUPovMyoDLXeE=; b=LLU8k/94tNYR1Q/VOlDDmvbUEWDS5kNrmbT1ezhAlBNzte3vwvZ++xaNJjhoZ3WdZy 4jBM4wmU7WxS6SJV+e1Aczi1AvW+w0oDnAUmvQkw1qwlXS+eaL5v+GIYWwr8LZrtWu7d 4ydvra0DcThbt7iqyfwV5IXTeAGo6R4gqJEnrMbjx5hOZw6wXeBVW3x0vy+C3S3Iq5s1 rjtJ70spr3SmnEfFqGc4RQSQRWLL5DaR2KH0M0G6CodhpQ1k4okciBVPjq98/ZiGHIWa EuflDsS3xI/dRSXgv/wGRU9rxpSD/lFLYvboRmNX/pSCGop3lLY5qekVU9inqHAmUIRH +aRw== X-Forwarded-Encrypted: i=1; AJvYcCUd+V4CBise6Ak3uDiyPSchF5xjC3jTsUcwxEJNjN8nPEBKU3/HXlXVSh3CNxKfdEX7hnNusJV19g==@kvack.org X-Gm-Message-State: AOJu0YwQuaDfFIp+gk3KPcmFybYP1ASO2Fk+Kj6nim0lWPd3XtpMQBHn bitPlWEfni12xWZVkKIhNPtDrEmf0ft7uyxMW/jXPsVzoJ9BaH0WPsiQcB+LFWfcDaQZbnVEa3R Q03heJumagRuNxJnwrZ5n2WWx4gN+VoN2o/u9 X-Google-Smtp-Source: AGHT+IEbKyyCb/ML5+UgYqhqK1/RS6RIvLVjm0XzQnqug7sH8rzZxXoc8TXSfeuvq+9nVj+ZlrnSr4B6zMcyIpPMF8U= X-Received: by 2002:a05:6512:282a:b0:533:6f3:9844 with SMTP id 2adb3069b0e04-53546afa387mr160737e87.11.1724976891667; Thu, 29 Aug 2024 17:14:51 -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 17:14:15 -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: f543y3g9c33k9fsguxhypygnps6ojqgp X-Rspam-User: X-Rspamd-Queue-Id: 5CE1F120009 X-Rspamd-Server: rspam02 X-HE-Tag: 1724976894-387501 X-HE-Meta: U2FsdGVkX1+fgxj244m8QhNxZI3aDnIEKUCSz3KQi0y2KC38oQkf3a5jxeDQASNKfBch5k1HCnM4q92nfQ4PKKWwpclZMZN+a6bgaew32WLmM8FBqZMcZMCOxTaWFlai3dVshOhy9cH0Hw5kaRQdXskLtdLqNfK6FF4rK2d1na4dkFsTIajCjefV1PbEYOl+MOjtMoG/ql75Yuv9nn/HqPoL2kDTWW+i8SrONQ2A2SgxUlLMcWv0WlDBcI5FAdogENPw6Mlt9UKtHCtWrhZeeZ85YXimIMiuJ5Yk+gEhh2PdGl9ij6TyqVi+6A9frCeBfLwkmscJVXrwcxV4jd0E7/sVtqjtMgkn9mgBhOO/sTVipUZnfC7fF7NcLeVoODij7zj8XRy8O1lrpPRkancESinDt6rJpzCgaBhNV0YTtojsys7i658wFAHxf5a4L32t0q0sGRw5YUFjAUSguJzyOX1mPNNt6CTnRD3oYcQ2zaiLgSPfJ+Y8QN1leNvV1TJ+/RuPyluzhUqJMFiHCjZFoFpAZNv9TX/JK0ixjs1eaG1y3sQTwr9f4APTlwdSAWGDUReWQea+RvS2QsclxZo7PRyGaskwDyjxb2qM86jKND674kyTXsB76+d+K5IP56ozQZuCf+mPIJnqZndwGb12hVmmMK+6w9Ds6PyTVg3l48HrXqVJfQzeUB8WzHBsS53zMCbk40ldwULdyihk3uFmGmrixjyFOa5ynHAPUyWj6PTpc+ILDAiN5oHbsGm0g02Uy2V8g9W7w76ov74wsOUkMXEHHD/vuSyN1hgWCgRAMGxkKKFEvAzCSEnZm/EizZthklfU9nGOjqBC/FpCVFPKJmhnt3p4ro6BlQuc3zfilFDhwlTDZpKc8+exLxrs8JVwo2Me2IRXYZjMkiWzfDnJDFpc3kblhvg1C3cSXWkEZXy2k5vFb4fDUho12x4kHLHk/VK1diK2x8QNNbUKD7D 1PNixScp 0lHacLB5Z/j32c1WgLHpi2JSRoBqHCrcCYmd7jZuFwqc7ercvF9YNUWAJ9g7UEk8jjdoUhBaTi6v/exVLlMjRpitIfgph8ACzPJaEjQFn6AErRVLiw7dy1iH+CfPXBCoOEJWzfCZKM4sXdkPqEPLnH6F8FW8Osfpc4vO05lQ12ABOWRJaNSbzoYS4PPdTpRpX2YcQFR5lBkCVFWmpiyhwZwsd9XDZoH1wHwJTI48alwv6Ay2mLqjJWHbsvg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.235784, 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 5:06=E2=80=AFPM Nhat Pham wrote= : > > On Thu, Aug 29, 2024 at 4:55=E2=80=AFPM Yosry Ahmed wrote: > > > > On Thu, Aug 29, 2024 at 4:45=E2=80=AFPM Nhat Pham w= rote: > > 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. > > Yeah something is fishy there. That said, the benchmarking in v4 is wack: > > 1. We use lz4, which has a really poor compression factor. > > 2. The swapfile is really small, so we occasionally see problems with > swap allocation failure. > > Both of these factors affect benchmarking validity and stability a > lot. I think in this version's benchmarks, with zstd as the software > compressor + a much larger swapfile (albeit on top of a ZRAM block > device), we no longer see memory.high violation, even at a lower > memory.high value...? The performance number is wack indeed - not a > lot of values in the case 2 section. But when we use zram we are essentially comparing two swap mechanisms compressing mTHPs page by page, with the only difference being that zram does not account the memory. For this to have any value imo it should be on an SSD to at least provide the value of being a practical sanity check as you mentioned earlier. In its current form I don't think it's providing any value.