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 91A9CC27C53 for ; Mon, 17 Jun 2024 03:02:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 62E616B012E; Sun, 16 Jun 2024 23:02:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5DDEA6B012F; Sun, 16 Jun 2024 23:02:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4A5696B0131; Sun, 16 Jun 2024 23:02:50 -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 2EC3C6B012E for ; Sun, 16 Jun 2024 23:02:50 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 75C7EA133A for ; Mon, 17 Jun 2024 03:02:49 +0000 (UTC) X-FDA: 82238883258.22.D632C30 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by imf09.hostedemail.com (Postfix) with ESMTP id 3673D140007 for ; Mon, 17 Jun 2024 03:02:45 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=aN8UdNiP; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718593360; 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=vLq3aqMQl0YnCrCuF+VjPWb00ZyBd12twcenDEj3ZFo=; b=8ReYKp2CdZ2qn1fVC7zKt+SeJPhQExhRdXVYcKxxZy0quIVmV83t5lBRIdwsA9SaTcMafU tOLHmUvwycSp4tZTcbGuPhMqx6vohQolZctZA0+rkVdOXrWMC/5JlqszrguIRq2x7yOi7V aBhWqKHn/3Si7q+SxuAUk7Y4je0a6AI= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=aN8UdNiP; spf=pass (imf09.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.16 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718593360; a=rsa-sha256; cv=none; b=LEoikprDIPz6Ke9mk8VDNkGHajCv5f0Vkrn+vC24dx8Fpyfmv5Or/E8iZQSvjG+hVpPwgX BEu5EKJZ/LgSRrZhW8nna1npS8geKlwN/vv3JBr4mOhiU+PsHP2tCWnvyDfSdLLra/+dUu PdN3NAmeMYMFDDPqn4chKlnh8w0aFa0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1718593366; x=1750129366; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version:content-transfer-encoding; bh=JHm0iH1Rb3LqS2iI0OkGlo4WQOAGVuUe4DDjBAFzAs8=; b=aN8UdNiPItEBlj71t4ySW5LtMKxjW/FQI0HzqMj/XL3TQHJ2Kn7JAOEa W/J7qfpU7oWaU5QWpVBXbjuOfNcaB97a07kNAu1F4bUmL3QYsS587jZ27 OCagudrXg8axYh6712Uo3IaQZWQYqzXs6xu5zuXvcfbB9bUZzO/MLU//5 h2yRyVzmaeHtDvlpZRjzQg9zNgFuJDHCMa8oHC8CGkHSn6kgk2B3TxAA6 9hQBxyLn+UEQzNIShIMnm8m2WraD5K830BNLmmoquAWXV2qsbEktGjefP Hphx0tUYbTf+IGNXkp0XUXjZdFOfDO/igwvhZmFBR6hLZO9HLLIwolZjM A==; X-CSE-ConnectionGUID: 62qEf61NQO+BHopJCyPhww== X-CSE-MsgGUID: pVKSUEGkTYS9PwnqzMRn8g== X-IronPort-AV: E=McAfee;i="6700,10204,11105"; a="15543456" X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="15543456" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2024 20:02:44 -0700 X-CSE-ConnectionGUID: 8drbOxcXRJOZxX7pLAGixQ== X-CSE-MsgGUID: VoZAwEpqSROUevimrQ0sFg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.08,244,1712646000"; d="scan'208";a="41776956" Received: from unknown (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Jun 2024 20:02:43 -0700 From: "Huang, Ying" To: Barry Song <21cnbao@gmail.com>, akpm@linux-foundation.org, chrisl@kernel.org Cc: baohua@kernel.org, kaleshsingh@google.com, kasong@tencent.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, ryan.roberts@arm.com Subject: Re: [PATCH v2 0/2] mm: swap: mTHP swap allocator base on swap cluster order In-Reply-To: <20240615084714.37499-1-21cnbao@gmail.com> (Barry Song's message of "Sat, 15 Jun 2024 20:47:14 +1200") References: <20240614195921.a20f1766a78b27339a2a3128@linux-foundation.org> <20240615084714.37499-1-21cnbao@gmail.com> Date: Mon, 17 Jun 2024 11:00:51 +0800 Message-ID: <87r0cw5l3w.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3673D140007 X-Stat-Signature: ye7oqhwsecsk1g51fepk9umco7iemp6e X-Rspam-User: X-HE-Tag: 1718593365-400428 X-HE-Meta: U2FsdGVkX1+hGcAKDwqGRwtK81vk+SnBGWXPLJYJ8KHOh+vq4ZgIOyxbJ+LF4yqeTXbaCWvDcdOja7VXFn6RKjuBU4Xu3odMsNSoaJYQTtKZnRuRzukTrO7eF/EffdniaEX57S6+sK+90R0jaIsLu0FQhx0LtCvwX9BbGpx8Q9K8qyrpfO6yprp7N5QRJRf3rFalCPLKiht1/oi/E1klx7fKNSQ9POLQjd0KcEqA4U50LUSG9BXBr/cOmDBL8taVU05yTusSiZ59b4KBSJdt8lZGmKTIT/ZAgJKI+Jzsg6J/Qg/CtVuYPkpJQno/fCQT4qPvWYsCt/nx0L6RnUvjxcd6s48tjQNqk+nWEMJ6HeDdh+iC92SqjtovqBLLO+2f/tLRY9IjCRnSVzGM5b96duA2JsiiqQ6RomDxuZJPWTq28BvyRdas5/zOC0FS6d6oRxPHTebAAo/XOAbFPBhT5hz8/rzSF6XKHdr+hhaKm9oMN/dBFDv2u566TPBoSW0KM0IKnz/HZN4vVqQgIn+MyRUhpnTpsRB5EQK14VE1w+7aFshJgq7yUB/JJSyziZBCnl2TfeM5cGi650VsZqcZICa3X9fmDwIIOyAvCbVQEsMtKwuDdBkU8ZFyoHUbpuwuWknDRy4PsZuUnwsM1qkBUvYFxSsJmDkOcM21IlIkxUrxAOPxshQ4LRR3ZL5T8kSALr61UpxCzk1mAtuBPduR4bAZSzlAfYYA5i27CKhx32DdghAu9iJYSIp4QjAw6d0ZbNsg+z6WC07e1tQpLYHci8VuJojodbHKNrrL5M5IHJ3ZvPhc+8/ZHyylQogJFhW5MeJ9aOd6jJZqUReAO7F9KMJFof6C05iiP7VG1rYg6rhbhXH8EcwAYpzd6CueaKTfb3713mXRUi+NT+HdntuHKZkSdys43QUXCY4y3QNsvYxJjkEAGzYtvav6noCzs5pyIKt5k6mtVNj0915lPOz hF0y9MEa pZiieWKtdsErn8XEIm2Qg1tp1vfeBxTsQKybYsPkwFtQOrDTRZ2uL1VYd7N3Z6n5I3e4db5CtM4Be3RfAu0MtuQXIN9e4txVfW2QMHWU2LPQaBUfeh0BsPKiHuKO3vHhehXaZvY9BAFpNaXzhQyoH1mc0zNlgVffERAo3i/47rv9nQ05pOUUJFNzqhn9XZX7g0xaugHQ34JY08M3vzkTmIoTDwolhezACCL6cwsE85PG9b/xjjhQXQ/efpgHH2EClUsP8NrA9VYeHUisJQ9iCJwXIXO8NSC6zTMK4 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: 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 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. >> >> 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-47861b423b2= 6@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 pro= gram can > demonstrate the problem and highlight how Chris's patch has improved the > situation. > > To demonstrate this, I designed a basic test program that maximally alloc= ates > 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. Thi= s setup > allows us to assess two effects: > > 1. When we don't enable mem2 (small folios), we consistently allocate an= d 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 may = lead > to fragmentation of clusters, potentially impacting the swapout proce= ss for > large folios negatively. > IIUC, the test results are based on not-yet-merged patchset [1] (mm: support large folios swap-in)? [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