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 6CD6AC27C77 for ; Mon, 17 Jun 2024 03:30:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C567E6B0133; Sun, 16 Jun 2024 23:30:10 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BDEC06B0134; Sun, 16 Jun 2024 23:30:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A31996B0135; Sun, 16 Jun 2024 23:30:10 -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 7EE076B0133 for ; Sun, 16 Jun 2024 23:30:10 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 026461A12EA for ; Mon, 17 Jun 2024 03:30:09 +0000 (UTC) X-FDA: 82238952180.11.0C07FC4 Received: from mail-ua1-f44.google.com (mail-ua1-f44.google.com [209.85.222.44]) by imf23.hostedemail.com (Postfix) with ESMTP id 33184140010 for ; Mon, 17 Jun 2024 03:30:07 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bf0wUV2I; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@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=1718595002; 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=uVE2ZGR0YoEn9niDLED97otBK85UxDw7u1+BiRikU6k=; b=SgSR46kPlAJINEe0rw3+LCfmQx3dhp1VjHaZAu+bDp2enyUz5gVL+X8vAOza4bO/AbaR33 e/h2Nrn/Nr8I2lme5ybk7TTcTnXFGFR3WKMhk4ritrARsWPA2fyEqxl2N0KSvIoGKoXnnz u3klmUlDiyJjC9r0yFTq1TiRVzrUGWY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718595002; a=rsa-sha256; cv=none; b=rLR2/AyQ5hCSpokgP8Z4XuMZZ21ayVKMGP/j+sbxD9z166csEhx//r0n3218IoDh7w7maK tnk/wlDaTDbRjjjny/VLQtotD5Yi1m3FuH2tlnNmMosuJf+0PF5jriwjLlXxlhRNke4dd1 QYufpD9WV855jEO1TlG9cIFvYvzJRb4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=bf0wUV2I; spf=pass (imf23.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.222.44 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ua1-f44.google.com with SMTP id a1e0cc1a2514c-80d6cf96e22so2336974241.0 for ; Sun, 16 Jun 2024 20:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718595007; x=1719199807; 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=uVE2ZGR0YoEn9niDLED97otBK85UxDw7u1+BiRikU6k=; b=bf0wUV2Ihfx0q5tpx4CdTvC4mU5XLGi7bUwzPiC2nwkgWRLk5oalj/5vz4xd2dJkx1 CswxoHE7LYRk/PXr6PhdyRYbwjXm+GmLrjdyX4PNYUmX3HLAO3Jjr21TW/aQymbZV3BE OMxtHJIjAncim5dj+WFO4AS/oC+Pkp1FcXVo+6JKy8FGLccxvVpgzqHC/lcmH1DcRRI0 Eh1sxY86oSNaZuRSCfcEpF23squJ3RjcSWoCAkbaa7G5im/627AYEzE8cZBrGAkyY+dj XV+GknLb1zgbiBagSECdRVj87PjlUHqbkMWBHZZzOrKzG5ZDjnS0Ydi42SfOUASmaOf4 JWbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718595007; x=1719199807; 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=uVE2ZGR0YoEn9niDLED97otBK85UxDw7u1+BiRikU6k=; b=ZF3eo/sBXNPEkMobZF9U5Fr+ii+pDNXA7jgN/XXQ7aom0TYDVRNjIe/f38jW5YXiK/ Zw1czvfeYcXH6Z8TxQyQkFjNjUrqXmLDsifZC3zdQ9LMzwnmfqa2OUAR8RqSHNLS5qch gkd6b0dTqnkMLNIekFpzhDsatc1mBWHiYW5LUObiujb74vLtJIY+E2Jjn3oaaUUg4/4V T05MVw7AzMf1WhozUo73Z0vNMZMgdN+wrnF4+59kcUgXCqkrHlU3Rk7e7oimxzLVjXXK GEYp4pZ8mICyyJlICLTj7JwK69reYn2swlAvSfeizzaUq06ZvBHE0nxzq9qiumkz3zri Up6A== X-Forwarded-Encrypted: i=1; AJvYcCUaqt6r+K7HcFM9TNdDxBUduwNpzflu1fCailwZWhsZ3WTvTGyRkiut/Uj6voqWtjSw8iQXbiaz4JTCfqKZGI0yVlU= X-Gm-Message-State: AOJu0YyabBdMLumXNDT1Bw5tCOo+hY28/3FwxkGCGFpewsnvoPQ+apcn lFgdLCq4jpgM+wJq4QVzojEg6NA76iv3i4DuxRfCoksGCcp3++eQoqbU7UAVNAm4Uh3pJsNybij CrBGPJAQqvH60CVgNgsyK/OhgIHs= X-Google-Smtp-Source: AGHT+IGmY7HvGHTROV0uCRoY5H4XlD16NGR2L9QNfEfcGVcqr7kRVUjQpe75i6bzfPD2d5pU8bEzFRzpvuNZQGymQPc= X-Received: by 2002:a67:ecc1:0:b0:48e:f1c5:6408 with SMTP id ada2fe7eead31-48ef1c568aemr1230782137.17.1718595007017; Sun, 16 Jun 2024 20:30:07 -0700 (PDT) MIME-Version: 1.0 References: <20240614195921.a20f1766a78b27339a2a3128@linux-foundation.org> <20240615084714.37499-1-21cnbao@gmail.com> <87r0cw5l3w.fsf@yhuang6-desk2.ccr.corp.intel.com> In-Reply-To: From: Barry Song <21cnbao@gmail.com> Date: Mon, 17 Jun 2024 15:29:56 +1200 Message-ID: Subject: Re: [PATCH v2 0/2] mm: swap: mTHP swap allocator base on swap cluster order To: "Huang, Ying" Cc: "akpm@linux-foundation.org" , "chrisl@kernel.org" , "kaleshsingh@google.com" , "kasong@tencent.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "ryan.roberts@arm.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: xwuw1fxixmrr1jhjm9rkaiykm6ukof1n X-Rspamd-Queue-Id: 33184140010 X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1718595007-597649 X-HE-Meta: U2FsdGVkX18Jl25gRLIsRoep0NJ3e0WvsF52OC3F8QUscyyFb0OcM1B3H4hpkDkjSmUFf5iaH+6GwquSwVZw7mfIXeljpCGJ2uUjGhc+/RizvOdGUFxxpoSj7QYJ5nWgpqQurFwbvUfflSF3o1ydsbjq9KddO+Ukups68o+e3nR77qm7hmRKRIexrRI8NhYtlWEX3QU6FrYn3c27x5goAiyljTkh010Qv2KrV8G1WCmi2K2t/IKa7LNh42t7m2LJmUDUu8vq8Ca2cc2qP8Qo/mPsHBFxd1QQsfMh2LtkTNKU7U1hOyl6VbxkwS/TjnaiwojyKMbXiwlBww2bzzu1j/tjuEaHO0tDOih9U+N1hqePfSGatPHm/yKo+XDJsalpKHqDp6GfuYyukKL/212q0/u8pKvufT1yxRBinCUkgD9HdSCzbmPS7NY4vRnVv6xjTgT5LXzVCK5uF5UueoHPuSyHQk/YzNRriJD3uClvrFIP1pAUc8bo2GBTFuHBIzMOdOMNj1/qVrCGncXnni6hOKKOa5WFIh4RqnPfAgcMnRztk/quY0f8UNgROyV+sAbiNDOujFzqqMNqXwhZ2CRS4ghiALmQF64qZSrRhL1/lX8xhX/LsBYuk6MMV6McoojZuEzH54daWRz26KKhKkposHnTBlxV4bZCtfcYWjU9lGanCIzUyXUID1j15/yl0bkvVhx0zbWmQlnKCfUEaNoEWn74f171C6jKaAaugfC2gfCiNeYt03ZlW4a/HGeZsEqN8PjUNRmsL5dlMIV2ToEttMClPlpUDxRCC/9sSLJHH3ZhE0HejRbFhVwBJorCjzU30NZxNREaJ8F5U9T3BKlfCXMO62yZYQh/p3EW9BVXk2p7XbNliCF+2p8FpODoS0SjWTP4jAwN+n02qvyB3qLvrzG/a5+I/KfgIIJeVqCWnyswL6qcGmnGoKE+vl6wCopYXYlBNsCZ9XbXZCLgQCw AmQh9w10 i1w81cd9UzdConA1nisUn++eFGGE3L2VcUYraUGALIZfkAyf1mqYLo4X0gMee14xfwnjyQq6uqVn94k0Gk+6xsJrzbUaIPihZDvLGxuOyh1s06j5Y+AwTkzlrxG3oVaX1Ppx9fv3Oz862nixT+ScbFs3lV9jPDM1diUJxF9ZFWiFo88YN3vtNnx26RR5tX+d67JzyDhzR9Aba1uCULxP1wf3RZnHaU3IVkOmtd8Y33nFcNzoTbgoj8poupEISXa7xeJPF0FP+QQ58qahCujLe0UpRE3GOpsiF0Gn+lIJbWmrBDTtvntEwZiEIgu6DwBL96sTBvyFadF4fctncwbKRyaSjYA679DA7dJpta8HPkXr3EbojvuARMIZDCXLxCGpVjA8JnG+cVVN9lVkKb10IOA5UvHSOJ7wrdoecwFeQWW6LJxplfhMA6Png7Dz54oaPgm2qdTP0ze4hyIacKtGLMYnoNabHUspWvUcJMq/CoBKrW03ZO22gU2iukWvuj4pMn8S2NU07U4z8mssV3Pw4JmvRHtJfRvtpQKTQFMxrV2bmWcljPpQu4MCsTg== 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 Mon, Jun 17, 2024 at 3:12=E2=80=AFPM Barry Song <21cnbao@gmail.com> wrot= e: > > > > =E5=9C=A8 2024=E5=B9=B46=E6=9C=8817=E6=97=A5=E6=98=9F=E6=9C=9F=E4=B8=80= =EF=BC=8CHuang, Ying =E5=86=99=E9=81=93=EF=BC=9A >> >> >> Barry Song <21cnbao@gmail.com> writes: >> >> > On Sat, Jun 15, 2024 at 2:59=E2=80=AFPM Andrew Morton wrote: >> >> >> >> On Fri, 14 Jun 2024 19:51:11 -0700 Chris Li wrote= : >> >> >> >> > > I'm having trouble understanding the overall impact of this on us= ers. >> >> > > We fail the mTHP swap allocation and fall back, but things contin= ue to >> >> > > operate OK? >> >> > >> >> > Continue to operate OK in the sense that the mTHP will have to spli= t >> >> > into 4K pages before the swap out, aka the fall back. The swap out = and >> >> > swap in can continue to work as 4K pages, not as the mTHP. Due to t= he >> >> > fallback, the mTHP based zsmalloc compression with 64K buffer will = not >> >> > happen. That is the effect of the fallback. But mTHP swap out and s= wap >> >> > in is relatively new, it is not really a regression. >> >> >> >> Sure, but it's pretty bad to merge a new feature only to have it >> >> ineffective after a few hours use. >> >> >> >> > > >> >> > > > There is some test number in the V1 thread of this series: >> >> > > > https://lore.kernel.org/r/20240524-swap-allocator-v1-0-47861b42= 3b26@kernel.org >> >> > > >> >> > > Well, please let's get the latest numbers into the latest patchse= t. >> >> > > Along with a higher-level (and quantitative) description of the u= ser impact. >> >> > >> >> > I will need Barray's help to collect the number. I don't have the >> >> > setup to reproduce his test result. >> >> > Maybe a follow up commit message amendment for the test number when= I get it? >> > >> > Although the issue may seem complex at a systemic level, even a small = program can >> > demonstrate the problem and highlight how Chris's patch has improved t= he >> > situation. >> > >> > To demonstrate this, I designed a basic test program that maximally al= locates >> > two memory blocks: >> > >> > * A memory block of up to 60MB, recommended for HUGEPAGE usage >> > * A memory block of up to 1MB, recommended for NOHUGEPAGE usage >> > >> > In the system configuration, I enabled 64KB mTHP and 64MB zRAM, provid= ing more than >> > enough space for both the 60MB and 1MB allocations in the worst case. = This setup >> > allows us to assess two effects: >> > >> > 1. When we don't enable mem2 (small folios), we consistently allocate= and free >> > swap slots aligned with 64KB. whether there is a risk of failure = to obtain >> > swap slots even though the zRAM has sufficient free space? >> > 2. When we enable mem2 (small folios), the presence of small folios m= ay lead >> > to fragmentation of clusters, potentially impacting the swapout pr= ocess for >> > large folios negatively. >> > >> >> IIUC, the test results are based on not-yet-merged patchset [1] (mm: >> support large folios swap-in)? > > > no. this data is based on mm-unstable. > > the visible impact is that swapping out mthp will have 14% regression if > fallback againest swapping out nr_pages small folios regardless if mthp s= wapin is there. Ryan initially reported 14% swapout regression without mTHP swapout. then he reported 46.3% improvement if mTHP can be swapped out as a whole[1]. so we will drop 60%+ performance if fallback. but the 14% regression agains= t pure small folios are unacceptable considering more than 2/3 memory can be swapped out on mobile devices. So I am hoping we can find some way to merge Chris' patchset soon. though the WARN_ONCE still indicates some BUG in v2. Hopefully, Chris can fix it in v3. [1] https://lore.kernel.org/all/20240408183946.2991168-1-ryan.roberts@arm.c= om/ > > >> >> [1] https://lore.kernel.org/linux-mm/20240304081348.197341-1-21cnbao@gma= il.com/ >> >> If so, do we have any visible effect without that? If not, should we >> wait for patchset [1] (or something similar) to be merged firstly? >> >> -- >> Best Regards, >> Huang, Ying >> Thanks Barry