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 9EE1BC2BA12 for ; Sat, 15 Jun 2024 03:01:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34FC46B028D; Fri, 14 Jun 2024 22:55:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DCC586B028C; Fri, 14 Jun 2024 22:55:10 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF8E86B02B9; Fri, 14 Jun 2024 22:55:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id E7C6C6B0246 for ; Fri, 14 Jun 2024 22:51:29 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9C90FC0A46 for ; Sat, 15 Jun 2024 02:51:29 +0000 (UTC) X-FDA: 82231597098.23.56694F4 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf12.hostedemail.com (Postfix) with ESMTP id A858F40009 for ; Sat, 15 Jun 2024 02:51:25 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uRnHVi6R; spf=pass (imf12.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718419883; 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=xUNrySc4ZkMgMdDGKOc9NdgW+MNGIt+162yLlWifTWw=; b=ufr+SiP/0qKeqOoxWzy76PgLkX6vptmXCk8OsyKUHKfESqRCaV+Ftl3WBllXipZedjIVru oJNrq0NOzXJ6lDEPecF5Srfj3oDRPf7e/nvJB0N0a2PXFRRx88dQF43V8z8IKw5j+IqtkB 2PlRINwV4r5KnM37LTcvMAGo8ER8nZs= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718419883; a=rsa-sha256; cv=none; b=45/EDPDIzDLf+g1LjHEoO7iTo359dUhz+GIQReTDVX5EM06Q7pcOjd5o2eJeylyG7OjWzm OboVUvewNvjjExm4uKeuKign3doKizN3iebZGYUkpAWoV609uwoJXtG6K/5gyFvfjC13Rx CL/fEYjx3biHB9PK04h+J8TDZfjeBsg= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=uRnHVi6R; spf=pass (imf12.hostedemail.com: domain of chrisl@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chrisl@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 744DB620F7 for ; Sat, 15 Jun 2024 02:51:24 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2AB25C4AF1C for ; Sat, 15 Jun 2024 02:51:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1718419884; bh=hzi5z305rKc8dBhBbV12L+aW0t0uf3vTIaGYA2JEyow=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=uRnHVi6RJfhc2x1SI9E4uMlPJkB+SthoGu/EV0JstH1PivYbYn8W/dVMBqAmzkMjm h2D8GbDpaXcK0q8B5fx7IVXI0ohO9L9Vu3mhMHuzSRbYF0lmgzULecVE0IjpHOoNVh mIZOadwtUoniRtAxCGa5GNyZCa4eAop448B/fgwCzoq1BRx9SzGA0m9x9PPWubS2/F vQFKaiHpNpiASTCWddXnINLuxrj1nsEqPloBOARPSErkVInvxJI9yLph/Oa5iRNFK+ 9HjnlAB4rzFte3vFBKMg93lkVIXGoYgAJeGyopVZKcVGmh87Yrj7xmkWQzmpzfv8jV SXTdfFv8nFiCw== Received: by mail-lf1-f50.google.com with SMTP id 2adb3069b0e04-52bc121fb1eso3365001e87.1 for ; Fri, 14 Jun 2024 19:51:24 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCUpOQBZ/4fy5xhmNSiP0hZ+x7n306YCnfEk13O0zL/dWCeabUTAdgOHYnJwVFdCOjVOCjK2+dAgqmfzGh4FgBEgWj0= X-Gm-Message-State: AOJu0YwsAXsqp6cxmPu8Tu8qXJYMRj5kzccVJnc5fJA4T+WHBGmmaIkd DN7a5a+Iohxm/AFl0GFqPbLylFj14Q749V7w3rt8ntbzU2pfteUrGki64wjMPYIPLacoI1wjC60 1df9Fuzy3Zy4ZX1dnakBlvSmbTQ== X-Google-Smtp-Source: AGHT+IE8dUPtHypxvylrw+AB71eNYrAw2oIJ2PJBuO3mGPTftvYSz51CQy8hmvtoE7AzYEJOfKcySsZNAwSaGEkpyfA= X-Received: by 2002:a05:6512:20cb:b0:52b:bd97:ffde with SMTP id 2adb3069b0e04-52ca6e55d56mr2574730e87.7.1718419882804; Fri, 14 Jun 2024 19:51:22 -0700 (PDT) MIME-Version: 1.0 References: <20240614-swap-allocator-v2-0-2a513b4a7f2f@kernel.org> <20240614180606.5f3b6f4a6cd515df30b7a0e4@linux-foundation.org> In-Reply-To: <20240614180606.5f3b6f4a6cd515df30b7a0e4@linux-foundation.org> From: Chris Li Date: Fri, 14 Jun 2024 19:51:11 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2 0/2] mm: swap: mTHP swap allocator base on swap cluster order To: Andrew Morton Cc: Kairui Song , Ryan Roberts , "Huang, Ying" , Kalesh Singh , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Barry Song Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: A858F40009 X-Stat-Signature: a7kg3855aq8s6b7ypsszoq8xi6mffrp6 X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1718419885-360502 X-HE-Meta: U2FsdGVkX1/kHUyGRVgwberhAIjL+f/jO9kAyWSzGboPvkYqV6WeqSQNwa7sxhaBkcWSOVtsWv8Qik9k7xBwK6RH4dCLiT8/Us9rR3BK4b5vO0CwrWz4SQQGj+ILl1WxZjQcgeeftikTsRktziqLHlXrAYv9zOiQWR2Qyt773sl+1q/6GHnedxUssRBkR7TGudQeVySDkGHXk4Q9l9DzMEmhYAzWUT2LZDjqquBtlR70sOGueuAoJB/1GtLHjjnNgsVH1IwPpZ/DVkYbsAgDjGJ257SikgPPfJ255Y1kls/q6QsxJMDUmRLHWQpV6UvSrwlx2XPsoN/CQ3y9R+25rmAmKi+TOTKOhgAkvXCt5mxz3cLByWAdnA41ssBtA+dDqNGvpYhrKjFYE58Gu+QWvlonAPE+YAzCq/Ir+eEjFHxvLqiBeFvGItcgmwwHxDBZr29J9jNeRFLg2dX3EyIOFiGm3drVz2JeTSJz6nJL1z1EOgwIlhD+UF7Vp0mbj0D8Y3mEiCqgjnodBkh/xPMJLU/9zAtSvkJ7gjEP5Xz/4vzj4+Asqy5lgyPXbx52NcGuKX5ioQajCGkjyNrgyopdzXER9+SUy6wgsp1mnsf+Fju7tmhSVfXfwCqz9EoWyf11LL8x5sFQ11BzfVC8jSF6bpzHSxM9N7G2OTNqA31Jdo6+V8VvdqwvmjpBTAJOiZ3IQ3gSNPXinWtsgLd7ig00K4z3PzZSm7mTVxURH7RpHodKL12vzUvVGxRIvw3SQwbL3G3Dkju/hkNVHbaFC99GyFOh7drEg0fjYQ1KryhDSAAaYYpxvDxiS8vFokIQ7XaI4LSSd/eMnvv9Xizw8g9T2k+QC6nbeMyYcEIXonuZz7x3iEJ43myjvJ+vRoJ//DA5AyT+16+23do4H7WY23lwl2PW0gbHyU6WHspk6Suu4wpUG0rO34gEKrZ+tiHb78pXvxbi5lNpg4Tug8HaY30 gZniIGGp aca3vc+RQFcAB2cSTC2dTK0AM6AWH4L5rd6mcveDDNo27x4RpIKZgNg/azGds53JATxkxq7JAMm8zRXUdjtpuYznmQYyhxqkLSDeomzN6WfWdo7mM6wkT2MRidbQAlsv6CSqFE7dcLiNnR5NdxCN1kRj7f8F3XzN3KuznDKPhowtHuP+kwmqiLDGErkLsrJqS16Qbv80Zp+mmS5OLv15eBJtlScUOD007CnSdP9zz6abxASHS1g9RpGX4ERsjYPmtq4uOibgd7+sdxUenvxkqF36tE0/lGKGz2zqJn5qzfzYYDsh7c1pqcrtICrR+YJB/EcmiDzX5/phYDf3qpP/Narqe7tc4rHjyVobLGVSZOw9dFtpLt3QRKl1G+2Rguu3q0b92dxru+O0hlms= 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 Fri, Jun 14, 2024 at 6:06=E2=80=AFPM Andrew Morton wrote: > > On Fri, 14 Jun 2024 16:48:06 -0700 Chris Li wrote: > > > This is the short term solutiolns "swap cluster order" listed > > in my "Swap Abstraction" discussion slice 8 in the recent > > LSF/MM conference. > > > > When commit 845982eb264bc "mm: swap: allow storage of all mTHP > > orders" is introduced, it only allocates the mTHP swap entries > > from new empty cluster list. It has a fragmentation issue > > reported by Barry. > > > > https://lore.kernel.org/all/CAGsJ_4zAcJkuW016Cfi6wicRr8N9X+GJJhgMQdSMp+= Ah+NSgNQ@mail.gmail.com/ > > > > The mTHP allocation failure rate raises to almost 100% after a few > > hours in Barry's test run. > > > > The reason is that all the empty cluster has been exhausted while > > there are planty of free swap entries to in the cluster that is > > not 100% free. > > > > Remember the swap allocation order in the cluster. > > Keep track of the per order non full cluster list for later allocation. > > > > This greatly improve the sucess rate of the mTHP swap allocation. > > > > I'm having trouble understanding the overall impact of this on users. > We fail the mTHP swap allocation and fall back, but things continue 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 and swap in can continue to work as 4K pages, not as the mTHP. Due 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. > > > There is some test number in the V1 thread of this series: > > https://lore.kernel.org/r/20240524-swap-allocator-v1-0-47861b423b26@ker= nel.org > > Well, please let's get the latest numbers into the latest patchset. > Along with a higher-level (and quantitative) description of the user impa= ct. 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 i= t? > > I'll add this into mm-unstable now for some exposure, but at this point > I'm not able to determine whether it should go in as a hotfix for > 6.10-rcX. Maybe not need to be a hotfix. Not all Barry's mTHP swap out and swap in patch got merged yet. Chris