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 22A4CC27C53 for ; Mon, 17 Jun 2024 03:12:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2DAF86B0131; Sun, 16 Jun 2024 23:12:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 28A726B0132; Sun, 16 Jun 2024 23:12:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 12B106B0133; Sun, 16 Jun 2024 23:12:52 -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 E93676B0131 for ; Sun, 16 Jun 2024 23:12:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id A0D7D1A12EB for ; Mon, 17 Jun 2024 03:12:51 +0000 (UTC) X-FDA: 82238908542.08.513D162 Received: from mail-vk1-f177.google.com (mail-vk1-f177.google.com [209.85.221.177]) by imf05.hostedemail.com (Postfix) with ESMTP id D0B6A100005 for ; Mon, 17 Jun 2024 03:12:49 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lacqH7MJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718593965; a=rsa-sha256; cv=none; b=iNqikBg1oFuoFjqJTVjv3SLAL+ZGyZkUW9Y32xvT1bYU3D404r/NL0zK8Zod7Onnoto4uj 09dCdd5kRDbBEserv0zaucVWPWJcZXU93nItAcK3UQHAAsbC1l3qfxPDgP6rGI5hjFv+pE 1DVkM/AmubjHIZHorpUZNr6yXBwF73o= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=lacqH7MJ; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.221.177 as permitted sender) smtp.mailfrom=21cnbao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718593965; 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=vrVO/vzwzYlc12qKB32WQJuP1xYGMccwb8Sdi5ovixM=; b=jKbgRrYespdI87bjg+IL3FHsBRYxlG8RHUxs9D67yhcfKXimOYT9FNbKIZbGkq4sD4I9PH ODr15eZYjL0J4DGsNRkUjEABzuOgciQh/6T2QdeUreoDxy+iMkw6NAFc3WNYIhq0lehdMm u9js6vMpG1vQoxqRTBnDYlupv2KPAzY= Received: by mail-vk1-f177.google.com with SMTP id 71dfb90a1353d-4e4efbc3218so1669469e0c.0 for ; Sun, 16 Jun 2024 20:12:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1718593969; x=1719198769; darn=kvack.org; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vrVO/vzwzYlc12qKB32WQJuP1xYGMccwb8Sdi5ovixM=; b=lacqH7MJBavGQvKcBTsYRB7SzEuF5JvsfvQrbV2qbFwiQvNPVuhrNjcUWMSfQw/7RO /7ntfQ7ruBx4iIZ8SEGgbYViedyw4zXXWybN9Mj74vob6FzLz0/XnY6ZdjJHnI+toX+A uUK8tMjxzGJR8fmxYjKiGbgQMsNEZm8r+I5x+fXeAd/mJKkVJZgOzIDS1DwtjpXdKNAq OBLnRFDrtOjSjfnCbeBFJWyzJXDsvAYDWeGvQ7Vf5u7n+S4veUc7Que6kAhxycbXTtuQ ToVHlcBa+ODPmpvW7SMHqhLFVrOjCeSPDg3s0VlaPYkr/dYBfoMIJozxSaOw47M/DqQh h0yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718593969; x=1719198769; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vrVO/vzwzYlc12qKB32WQJuP1xYGMccwb8Sdi5ovixM=; b=JEPqrwelSP0wdNZaiDlE63SmZaQQeUIQ+qYthCOv5tldH1n1SGZrqZY8gXetWL1iaL ui0ICGVyXX4qcnKaS9KODDZRcXNsj83NwfKotdA1Z+mMiDqkmf663NQFnNcs1CbqHiKd 6ZCtUZY5Q8tXEIGD+FCDQioiqQZSLarZIKb9fS391B8C9jTBjEX0nj1mdrYbo5unJ5Rf 9VMhJ0hUqXiurtCQHD7vT0VQ3suRzNZ3I5X9loi9BHByvThFmCRX/P48gIpy4b4Creeh fJpR4/kJtEJpKBb/sVH7txXUsoUjqytpApfWy5JEBZl8tV67Gsl4L9/zJamFxFhWsHnX k5mw== X-Forwarded-Encrypted: i=1; AJvYcCV9S8g4LHt2cLzJp6A7pHnTS5y+1X07yp+Y9pzPd11VINOaaSUXbYJ0xkV5DUvynXI1J6u+hvk+61A/JgmNvMBVHm4= X-Gm-Message-State: AOJu0Yy1/o0Y9nEWPtjqRT2pNORm25m5yWrScRLBxOm8T3sbBYRJh1v2 hQgFkholKfWmkvKDZlSKy12Zt0vJxVnTJ32tG4mz5hVSY5aCEr8lgRUeUx2F8bjpkv+DO19kry2 TF4lYlBLpFAzLbI8NkebtmSoJD9A= X-Google-Smtp-Source: AGHT+IErISwdmKfB4vHZ7wkWQ1LJ5qHv9akMSo2T4W6lRdQsr2RxyJnL85J9E+Ab4RNclifnxcsqczieLG1rei4CkEs= X-Received: by 2002:a05:6122:8d5:b0:4ec:f758:e514 with SMTP id 71dfb90a1353d-4ee40731a90mr7376901e0c.11.1718593968797; Sun, 16 Jun 2024 20:12:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a59:a763:0:b0:460:7b38:9888 with HTTP; Sun, 16 Jun 2024 20:12:48 -0700 (PDT) In-Reply-To: <87r0cw5l3w.fsf@yhuang6-desk2.ccr.corp.intel.com> References: <20240614195921.a20f1766a78b27339a2a3128@linux-foundation.org> <20240615084714.37499-1-21cnbao@gmail.com> <87r0cw5l3w.fsf@yhuang6-desk2.ccr.corp.intel.com> From: Barry Song <21cnbao@gmail.com> Date: Mon, 17 Jun 2024 11:12:48 +0800 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: multipart/alternative; boundary="00000000000005ff8e061b0d5713" X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: D0B6A100005 X-Stat-Signature: 8q9f8oc9xihhqauhpqf6njcxdaeqrdsr X-Rspam-User: X-HE-Tag: 1718593969-7798 X-HE-Meta: U2FsdGVkX1/vS0H4YYqTztDB/wBzxxrIFwDUMzbpLQmtk4c2SjR0d5InFZdeE/CTmeL7kgWDcSvFjGW3HDE3S1ZQUcJWdXFaCjUMKWKf3kiTDxttD38qRzqKm9PsQILtPCVw0qk2DiGWVYm84YTDewgLQxtyGg3syA227muItOhKrB85tLgpQwYztVs/tLDMeJ93geky+9V1VkD8fsu9FOqw4jt7Nj0pujuGsfr2lC1JXzJAgvzqP9VUQJG+BRQ3fM8PzAYY96u/2X5fRhM0UJMmNo590FWvoAE0DKwaxJ1FU6W5uWKvvMUx0mkJNKi0roBr41kfMgBLCdb2jPFd0ozayFnRm7xxnwSVZ3T7ceHHpcBv4nTPxq0FCNw7E6I5Y+jBRfhD5WXDtpXjAjS5CLl6xl2wTP15b/nrei/LL5+ytKasz+8IRnCbvmESRum/9yJ0Lw0Idvqiy9dAOckDvJnVA92La6zFBkFE/EWZGQkKBSVv9ioTDCFRpFY0/ud91Yr3AvAd7zwWIHDc4ZyxSH7JQFmDv065V3Ra5g60r+IW8iCNDzH4SUCegzP6hthz8Melf5XCFWM/PEBcdOx25Zb1C76uWPL0wwJz6pD1tekCzuaMCV4+V8sg8g6l8oj/iAM50d3IO3IJYBzsOgpgUKYxKYLXK+aB1gIL+Q4BMh0naTdTJmwFlTm9rlKdAE9jG/9Z4WJTjtIp6GNXChlV+TYnVsslY1KT+Z2QmSjrJcpyDDamyT5IkjUa+gJogkWeUXo44SDMTMnaBEIORnZOLQrXwEPyiHDPiEKCxXl4rwT6B1fW5X7K/ayj0ZT22uPIhAK28w+AJP2nbdWhAaH5OljP69lWit3d7tiLI5etFtYDG+Y8r2DdBqGIQ0Qxc+38fFOxR4gpeqWD72VYX0ZD32HPH35SlsRj0pi7h4qrI++oRCMJ7HIVCRsA2WmNAa/4NASi31ZbsL3X4gsXoAo rwG0/9nj xYeWrsN4GKbv/BsT/hTEgwjkJTzBbCRt4rIwFy3grOENjj8ArH1RYvuhFMWGJRxOi08TbIWhA3W/geslKKToti7zyuYt7DWva9ZC+HGCAjFFMoBd2wre9vHhoXSa0ZON8NrjpoSOBqgb8nL5ANcnjTPLTEqnOyJl0PgBD6nlJGwq3CHSBELBeWO85fmx5fs0jV5T+Imcr1MmF+IM+rE7hjKLfn2TgeBSaDEperOWjHniCZ5/4L2v+QQJKgGrH3ZPSEg11G2/Aj+PamY/3qhSGITqZNO++eWmDR2h5KFINnNrpgwaWdr0ohn7W/T1gs7WnsLVbKHOz4Q40xYOp8S7yWIpHtAQRaWdQJm4nT4wO5kig0iaot0Gr4ncNGJsU/AesoPvsmKMOaL6Ko69c+VEv5p633f3JDI1kHClfR7n0hqAbwvWnL/V/xOu2QTB7MdEPBcO4Bwb+mZHrxIjA2YfKlajuLkledqaBPsixfnJQguDSO5s2p6nFL7CYDJEaDYyQEDkTgaj0MqIsPW0pTJtoPqeaZ/e2GuovlAj2aFc3q/r358HoDaQg8faCq0iPsh0I2bcE4OSzNLtqGxcMTDPcuBtOHsQzCvDvNdD9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001771, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --00000000000005ff8e061b0d5713 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =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 > users. > >> > > We fail the mTHP swap allocation and fall back, but things continu= e > to > >> > > operate OK? > >> > > >> > Continue to operate OK in the sense that the mTHP will have to split > >> > into 4K pages before the swap out, aka the fall back. The swap out a= nd > >> > swap in can continue to work as 4K pages, not as the mTHP. Due to th= e > >> > fallback, the mTHP based zsmalloc compression with 64K buffer will n= ot > >> > happen. That is the effect of the fallback. But mTHP swap out and sw= ap > >> > 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- > 47861b423b26@kernel.org > >> > > > >> > > Well, please let's get the latest numbers into the latest patchset= . > >> > > Along with a higher-level (and quantitative) description of the > user 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 th= e > > situation. > > > > To demonstrate this, I designed a basic test program that maximally > allocates > > 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, > providing 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 t= o > obtain > > swap slots even though the zRAM has sufficient free space? > > 2. When we enable mem2 (small folios), the presence of small folios ma= y > lead > > to fragmentation of clusters, potentially impacting the swapout > process 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 swapin is there. > [1] https://lore.kernel.org/linux-mm/20240304081348.197341-1- > 21cnbao@gmail.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 > > --00000000000005ff8e061b0d5713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=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 <ying= .huang@intel.com> =E5=86=99=E9=81=93=EF=BC=9A

Barry Song <21cnbao@gmail.com&g= t; writes:

> On Sat, Jun 15, 2024 at 2:59=E2=80=AFPM Andrew Morton <akpm@linux-foundation.org> wrote: >>
>> On Fri, 14 Jun 2024 19:51:11 -0700 Chris Li <chrisl@kernel.org> wrote:
>>
>> > > I'm having trouble understanding the overall impact = of this on users.
>> > > We fail the mTHP swap allocation and fall back, but thin= gs continue to
>> > > operate OK?
>> >
>> > Continue to operate OK in the sense that the mTHP will have t= o split
>> > into 4K pages before the swap out, aka the fall back. The swa= p out and
>> > swap in can continue to work as 4K pages, not as the mTHP. Du= e to the
>> > fallback, the mTHP based zsmalloc compression with 64K buffer= will not
>> > happen. That is the effect of the fallback. But mTHP swap out= and swap
>> > 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.kern= el.org/r/20240524-swap-allocator-v1-0-47861b423b26@kernel.org=
>> > >
>> > > Well, please let's get the latest numbers into the l= atest patchset.
>> > > Along with a higher-level (and quantitative) description= of the user impact.
>> >
>> > I will need Barray's help to collect the number. I don= 9;t have the
>> > setup to reproduce his test result.
>> > Maybe a follow up commit message amendment for the test numbe= r 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 improv= ed the
> situation.
>
> To demonstrate this, I designed a basic test program that maximally al= locates
> two memory blocks:
>
>=C2=A0 *=C2=A0 =C2=A0A memory block of up to 60MB, recommended for HUGE= PAGE usage
>=C2=A0 *=C2=A0 =C2=A0A memory block of up to 1MB, recommended for NOHUG= EPAGE 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.=C2=A0 When we don't enable mem2 (small folios), we consistently= allocate and free
>=C2=A0 =C2=A0 =C2=A0swap slots aligned with 64KB.=C2=A0 whether there i= s a risk of failure to obtain
>=C2=A0 =C2=A0 =C2=A0swap slots even though the zRAM has sufficient free= space?
> 2.=C2=A0 When we enable mem2 (small folios), the presence of small fol= ios may lead
>=C2=A0 =C2=A0 =C2=A0to fragmentation of clusters, potentially impacting= the swapout process for
>=C2=A0 =C2=A0 =C2=A0large folios negatively.
>

IIUC, the test results are based on not-yet-merged patchset [1] (mm:
support large folios swap-in)?

no. this dat= a is based on mm-unstable.

the visible impact is t= hat swapping out mthp will have 14% regression if fallback againest swappin= g out nr_pages small folios regardless if mthp swapin is there.
<= br>


[1] https://lore.kernel.org/linux-mm/20= 240304081348.197341-1-21cnbao@gmail.com/

If so, do we have any visible effect without that?=C2=A0 If not, should we<= br> wait for patchset [1] (or something similar) to be merged firstly?

--
Best Regards,
Huang, Ying

--00000000000005ff8e061b0d5713--