Message ID | 20240216170432.1268753-1-zi.yan@sent.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:c619:b0:108:e6aa:91d0 with SMTP id hn25csp653387dyb; Fri, 16 Feb 2024 09:08:15 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCXKG00eR1UQd1/9ecbofsG9b+DtgSdLNdgQrUUdACZcZSFx18MblAYHRozeYl3ABibhJD70z6COIRH3aPHR6LqypQwWlw== X-Google-Smtp-Source: AGHT+IH2Cu7j7TndgakNtEJhHBbQCM6b6WbBB43cE1gi5j8Lke0YEyF0wWKHXEjcIzLTBdSBV1I2 X-Received: by 2002:a17:903:1c9:b0:1db:c00f:a986 with SMTP id e9-20020a17090301c900b001dbc00fa986mr260673plh.0.1708103171969; Fri, 16 Feb 2024 09:06:11 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1708103171; cv=pass; d=google.com; s=arc-20160816; b=PeQ75JgrMi58WDkraFRZN1CEIpKXHTgwScpJDl9ZcF6UQLd+gQLk2aRHwR7VXUyTe6 R6o59EUTzFEwOloWnWI4VV1NqQ0ferlZ2o/qkw5h5pMB2wPWKYl7xp3bCwbbNQNC8vPq ziAzjXXisNhVdZGw2fBdjc19FzG8jdDD9+3sp+n27JdRQhCFsiq94M8rDuXySZcf55/v MSQwjunP5My3gM4pqHfUbRQ+UYfEb4vYVT2XRzBBpLTSWK9/QOGL/SxOFcqmXrSoLpXn j5UJU337k/nwUGEH1BKtXul9d4P2XK9KMxdcrEGtuEISQ0niI2QAqUc0Hl5VBdByMMuz 56Sw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:reply-to:message-id:date:subject :cc:to:from:feedback-id:dkim-signature:dkim-signature; bh=ZH53TYSgqNLH2t7OXmnHBSODgAGrqTB8UB8RRzsq1uM=; fh=vJ0CYzlC3FzFcxY+JvdHzizIe8XjzG5USPt1Sa6qsGI=; b=pt+koE0Pp7mmvpvQFiwxjp49cTYCSg4SlyOgohN6IHSrNlRl/n4RVwlUJv2PHdMbVh 1mtcA+SWa9NdS5qYjXhRPjNdCyfgba+bUStp21xIgDRYdHlj+IehVDl8IXx/YjayHYqw 06RqhePwp/d8QJ9l992DseSq1q3itkHH6cJB3mTw7nufal9uqb1ORcVoP5IYABs6kZJs KGaLgcjwo9DZG8EbHRfH6lmJdiRGRedyEh0pAN/ohdkb2+yTvJDnnmoZTP8b0bwKxg/1 1MJaq0RNFx0P5WeTGqA45GVn243ojf7qbRK+QYz/wbS8yZWmx2zlrwkNKnRtfF1zGCCr HnCw==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@sent.com header.s=fm1 header.b=FZDfBj5s; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JN2VGths; arc=pass (i=1 spf=pass spfdomain=sent.com dkim=pass dkdomain=sent.com dkim=pass dkdomain=messagingengine.com dmarc=pass fromdomain=sent.com); spf=pass (google.com: domain of linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sent.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id q7-20020a170902a3c700b001db730d3f1bsi119684plb.610.2024.02.16.09.06.11 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Feb 2024 09:06:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; dkim=pass header.i=@sent.com header.s=fm1 header.b=FZDfBj5s; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=JN2VGths; arc=pass (i=1 spf=pass spfdomain=sent.com dkim=pass dkdomain=sent.com dkim=pass dkdomain=messagingengine.com dmarc=pass fromdomain=sent.com); spf=pass (google.com: domain of linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-69011-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sent.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 59A0E2820DC for <ouuuleilei@gmail.com>; Fri, 16 Feb 2024 17:05:37 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 7FEC4133286; Fri, 16 Feb 2024 17:04:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=sent.com header.i=@sent.com header.b="FZDfBj5s"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="JN2VGths" Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1A6D433987 for <linux-kernel@vger.kernel.org>; Fri, 16 Feb 2024 17:04:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=66.111.4.25 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708103090; cv=none; b=R5P26V2ud/4XTjptrqliyYuy/RosaHPhGMEbBhoXn0d2TN+vkwNMjAjWpDMoz+rbsZ0LnCWL+gJMpwCX/nvwIj1x37fvWqhYrvrKSKNFGuzc+DKI+9sSPH3sQ9jc37iLvui39eK/q7J5ghd9+wIPcJEzUMNQhLTyu440tFLEQGA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1708103090; c=relaxed/simple; bh=ub6pqJApu3aHhSCW8ZP49OQ/OImP8xXZtrj2SLi+MBE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=SQRoytH9aKUNRaanoa0M8lpiTy4jugjllA67yKG6+PflgjnTaqOhysuoHYf3SvRniHIO24+11kijQOx6Hi9a/Z4OBoJiw6yrBC97jWH8lqX/JJEftfLuGo7IhQldZfK6YxQGtJruNCGX1QEOqC7re9IX3dXz+kMxk6iyDbPiAvc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sent.com; spf=pass smtp.mailfrom=sent.com; dkim=pass (2048-bit key) header.d=sent.com header.i=@sent.com header.b=FZDfBj5s; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b=JN2VGths; arc=none smtp.client-ip=66.111.4.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=sent.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=sent.com Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 113095C003F; Fri, 16 Feb 2024 12:04:47 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 16 Feb 2024 12:04:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:message-id:mime-version:reply-to :reply-to:subject:subject:to:to; s=fm1; t=1708103087; x= 1708189487; bh=ZH53TYSgqNLH2t7OXmnHBSODgAGrqTB8UB8RRzsq1uM=; b=F ZDfBj5sgL8sgcGN4il/GLNbtHrmWPLHRJpMnsPvygDN1X8dD4nsC5i5QWH/V9zo9 wH2xpyuIrhxWiOImM4agTRiKVYfs1u4lmGbgZgUl2s0Z89OSwX9PbMo+iAveQE5/ HajGEHiaMIMPH5DTK2Y79Zot5vXR6EX/rz1J06U9L2SNj7Q4Ff5DCHneH7sg4KSG 2+cUnOIsYlAmigLCDnueiTqRlHZ5B8i2yZXZhwrgBJJTfM1YuH7XD2Gdvq/gmnTn 76uwkuQuhG49HGl+OmlMrzha5AAzOy70oCFNoVpq80+QQ69vsUbi7X6im9Q6+cMd iu/ktFJq/G8eGSm+DeTag== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:message-id:mime-version:reply-to:reply-to :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1708103087; x=1708189487; bh=Z H53TYSgqNLH2t7OXmnHBSODgAGrqTB8UB8RRzsq1uM=; b=JN2VGthsx20KKIlYf 9fqzmltovz9Bm4ed1Yy7kQ3IvxGjwWzRP48F5WU9JTeIE5pn22nvoPwaIu0Vdzs3 7gi3nSit/os/8jvQ7wxIDT7tNELfMHgIrNze/29pBgbg7F/vBbQII/DkpFEPn1Yi CDTXPuKyAiX9qyF+jTb4f24qsaqTzxvZfLx0rLLlNqJLOYoHfm/FALOewdOTUGkt rh8Z6+zVwcm2kMc/2nLN5SwV4wEJlYd+YgusvaKA1wlAPkw4onKsT+D6wqMKERzo ffxEsEHqwAmX2s7Yr0phMx/nsQycFFjyaGfIZKeT1j31HoCqPKNSREs0/1WPaUv0 YL8cw== X-ME-Sender: <xms:qpXPZa6HPh-c1AF64CJp2oTpQgepg0CKyGUVmDw1Ayeao10pKUfD3w> <xme:qpXPZT415LtHl6zeDHFAUaum970X0PC1uUY4UjvtMprnM6KYUQo9TwvPIZvgYaK8y ruAF7IFb_7apuTQ_Q> X-ME-Received: <xmr:qpXPZZe3iNhadhySCWIG-wpVvZP1ub5xXqJI7aFZ-maiSAaJIshUoqrzemQoFjEbk5_UJyPwdkWSmDOdwOeaouGNO-e3S9Ji2buQ0u8IBUMHd32ARSnjEDvR> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddvgdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvfevufffkfforhggtgfgsehtkeertdertdejnecuhfhrohhmpegkihcujggr nhcuoeiiihdrhigrnhesshgvnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpeekhfelud fhhfejtddttedujedtueeiveeutedutdeutdfhffffgfeufffhgeejffenucffohhmrghi nhepkhgvrhhnvghlrdhorhhgpdhfohhlihhoshdrmhhmpdgtohhmphgrtghtihhonhdrmh hmpdhsphhlihhtrdhmmhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgr ihhlfhhrohhmpeiiihdrhigrnhesshgvnhhtrdgtohhm X-ME-Proxy: <xmx:qpXPZXJBP33woB6L5OkHCPS_ZzYH0EN4jabbUl2C4FWnp0e42EBvAw> <xmx:qpXPZeINF5Z9Adidw5cuoOK56L4Hg1nH3C7YWutsFnaKTrGr4gZqAw> <xmx:qpXPZYyRiOdRwvdDPjOLor42GHmJSWB4dpenyeq82HnwagUsHs0vog> <xmx:r5XPZTC0plhXSZT-ytjmeZRwweQTscAKCqUl3jgfld-3bwjBNgPlYw> Feedback-ID: iccd040f4:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Feb 2024 12:04:41 -0500 (EST) From: Zi Yan <zi.yan@sent.com> To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Zi Yan <ziy@nvidia.com>, "Huang, Ying" <ying.huang@intel.com>, Ryan Roberts <ryan.roberts@arm.com>, Andrew Morton <akpm@linux-foundation.org>, "Matthew Wilcox (Oracle)" <willy@infradead.org>, David Hildenbrand <david@redhat.com>, "Yin, Fengwei" <fengwei.yin@intel.com>, Yu Zhao <yuzhao@google.com>, Vlastimil Babka <vbabka@suse.cz>, "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>, Johannes Weiner <hannes@cmpxchg.org>, Baolin Wang <baolin.wang@linux.alibaba.com>, Kemeng Shi <shikemeng@huaweicloud.com>, Mel Gorman <mgorman@techsingularity.net>, Rohan Puri <rohan.puri15@gmail.com>, Mcgrof Chamberlain <mcgrof@kernel.org>, Adam Manzanares <a.manzanares@samsung.com>, "Vishal Moola (Oracle)" <vishal.moola@gmail.com> Subject: [PATCH v6 0/4] Enable >0 order folio memory compaction Date: Fri, 16 Feb 2024 12:04:28 -0500 Message-ID: <20240216170432.1268753-1-zi.yan@sent.com> X-Mailer: git-send-email 2.43.0 Reply-To: Zi Yan <ziy@nvidia.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1791075991307820116 X-GMAIL-MSGID: 1791075991307820116 |
Commit Message
Zi Yan
Feb. 16, 2024, 5:04 p.m. UTC
From: Zi Yan <ziy@nvidia.com>
Hi all,
This patchset enables >0 order folio memory compaction, which is one of
the prerequisitions for large folio support[1]. It is on top of
mm-everything-2024-02-16-01-35.
I am aware of that split free pages is necessary for folio
migration in compaction, since if >0 order free pages are never split
and no order-0 free page is scanned, compaction will end prematurely due
to migration returns -ENOMEM. Free page split becomes a must instead of
an optimization.
lkp ncompare results (on a 8-CPU (Intel Xeon E5-2650 v4 @2.20GHz) 16G VM)
for default LRU (-no-mglru) and CONFIG_LRU_GEN are shown at the bottom,
copied from V3[4].
In sum, most of vm-scalability applications do not see performance
change, and the others see ~4% to ~26% performance boost under default LRU
and ~2% to ~6% performance boost under CONFIG_LRU_GEN.
Changelog
===
From V5 [6]
1. Removed unused parameter in prepare_free_pages() and used it instead
of my old prepare_free_pages_fpi_none() (per Vlastimil Babka).
2. Removed unnecessary INIT_LIST_HEAD() in compaction_free()
(per Vlastimil Babka).
3. Fixed cc->nr_migratepages update in compaction_free()
(per Vlastimil Babka).
From V4 [5]:
1. Refactored code in compaction_alloc() in Patch 3 (per Yu Zhao).
From V3 [4]:
1. Restructured isolate_migratepages_block() to minimize PageHuge() use
in Patch 1 (per Vlastimil Babka).
2. Used folio_put_testzero() instead of folio_set_count() to properly
handle free pages in compaction_free() (per Vlastimil Babka).
3. Simplified code to use struct list_head instead of a new struct page_list
(per Vlastimil Babka).
4. Restructured compaction_alloc() code to reduce indentation and
increase readability (per Vlastimil Babka).
From V2 [3]:
1. Added missing free page count in fast isolation path. This fixed the
weird performance outcome.
From V1 [2]:
1. Used folio_test_large() instead of folio_order() > 0. (per Matthew
Wilcox)
2. Fixed code rebase error. (per Baolin Wang)
3. Used list_split_init() instead of list_split(). (per Ryan Boberts)
4. Added free_pages_prepare_fpi_none() to avoid duplicate free page code
in compaction_free().
5. Dropped source page order sorting patch.
From RFC [1]:
1. Enabled >0 order folio compaction in the first patch by splitting all
to-be-migrated folios. (per Huang, Ying)
2. Stopped isolating compound pages with order greater than cc->order
to avoid wasting effort, since cc->order gives a hint that no free pages
with order greater than it exist, thus migrating the compound pages will fail.
(per Baolin Wang)
3. Retained the folio check within lru lock. (per Baolin Wang)
4. Made isolate_freepages_block() generate order-sorted multi lists.
(per Johannes Weiner)
Overview
===
To support >0 order folio compaction, the patchset changes how free pages used
for migration are kept during compaction. Free pages used to be split into
order-0 pages that are post allocation processed (i.e., PageBuddy flag cleared,
page order stored in page->private is zeroed, and page reference is set to 1).
Now all free pages are kept in a NR_PAGE_ORDER array of page lists based
on their order without post allocation process. When migrate_pages() asks for
a new page, one of the free pages, based on the requested page order, is
then processed and given out. And THP <2MB would need this feature.
Feel free to give comments and ask questions.
Thanks.
[1] https://lore.kernel.org/linux-mm/f8d47176-03a8-99bf-a813-b5942830fd73@arm.com/
[2] https://lore.kernel.org/linux-mm/20231113170157.280181-1-zi.yan@sent.com/
[3] https://lore.kernel.org/linux-mm/20240123034636.1095672-1-zi.yan@sent.com/
[4] https://lore.kernel.org/linux-mm/20240202161554.565023-1-zi.yan@sent.com/
[5] https://lore.kernel.org/linux-mm/20240212163510.859822-1-zi.yan@sent.com/
[6] https://lore.kernel.org/linux-mm/20240214220420.1229173-1-zi.yan@sent.com/
Hi Andrew,
Baolin's patch on nr_migratepages was based on this one, a better fixup
for it might be below. Since before my patchset, compaction only deals with
order-0 pages.
vm-scalability results on CONFIG_LRU_GEN
===
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/mmap-xread-seq-mt/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19+
6.8.0-rc1-split-folio-in-compaction+
6.8.0-rc1-folio-migration-in-compaction+
6.8.0-rc1-folio-migration-free-page-split+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
15107616 +3.2% 15590339 +1.3% 15297619 +3.0% 15567998 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/mmap-pread-seq/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19+
6.8.0-rc1-split-folio-in-compaction+
6.8.0-rc1-folio-migration-in-compaction+
6.8.0-rc1-folio-migration-free-page-split+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
12611785 +1.8% 12832919 +0.9% 12724223 +1.6% 12812682 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/lru-file-readtwice/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19+
6.8.0-rc1-split-folio-in-compaction+
6.8.0-rc1-folio-migration-in-compaction+
6.8.0-rc1-folio-migration-free-page-split+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
9833393 +5.7% 10390190 +3.0% 10126606 +5.9% 10408804 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/lru-file-mmap-read/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19+
6.8.0-rc1-split-folio-in-compaction+
6.8.0-rc1-folio-migration-in-compaction+
6.8.0-rc1-folio-migration-free-page-split+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
7034709 ± 3% +2.9% 7241429 +3.2% 7256680 ± 2% +3.9% 7308375 vm-scalability.throughput
vm-scalability results on default LRU (with -no-mglru suffix)
===
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/mmap-xread-seq-mt/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19-no-mglru+
6.8.0-rc1-split-folio-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-free-page-split-no-mglru+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
14401491 +3.7% 14940270 +2.4% 14748626 +4.0% 14975716 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/mmap-pread-seq/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19-no-mglru+
6.8.0-rc1-split-folio-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-free-page-split-no-mglru+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
11407497 +5.1% 11989632 -0.5% 11349272 +4.8% 11957423 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/mmap-pread-seq-mt/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19-no-mglru+
6.8.0-rc1-split-folio-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-free-page-split-no-mglru+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
11348474 +3.3% 11719453 -1.2% 11208759 +3.7% 11771926 vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/lru-file-readtwice/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19-no-mglru+
6.8.0-rc1-split-folio-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-free-page-split-no-mglru+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
8065614 ± 3% +7.7% 8686626 ± 2% +5.0% 8467577 ± 4% +11.8% 9016077 ± 2% vm-scalability.throughput
=========================================================================================
compiler/kconfig/rootfs/runtime/tbox_group/test/testcase:
gcc-13/defconfig/debian/300s/qemu-vm/lru-file-mmap-read/vm-scalability
commit:
6.8.0-rc1-mm-everything-2024-01-29-07-19-no-mglru+
6.8.0-rc1-split-folio-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-in-compaction-no-mglru+
6.8.0-rc1-folio-migration-free-page-split-no-mglru+
6.8.0-rc1-mm-eve 6.8.0-rc1-split-folio-in-co 6.8.0-rc1-folio-migration-i 6.8.0-rc1-folio-migration-f
---------------- --------------------------- --------------------------- ---------------------------
%stddev %change %stddev %change %stddev %change %stddev
\ | \ | \ | \
6438422 ± 2% +27.5% 8206734 ± 2% +10.6% 7118390 +26.2% 8127192 ± 4% vm-scalability.throughput
Zi Yan (4):
mm/page_alloc: remove unused fpi_flags in free_pages_prepare()
mm/compaction: enable compacting >0 order folios.
mm/compaction: add support for >0 order folio memory compaction.
mm/compaction: optimize >0 order folio compaction with free page
split.
mm/compaction.c | 225 ++++++++++++++++++++++++++++++++----------------
mm/internal.h | 4 +-
mm/page_alloc.c | 12 +--
3 files changed, 162 insertions(+), 79 deletions(-)
Comments
On Fri, 16 Feb 2024 12:04:28 -0500 Zi Yan <zi.yan@sent.com> wrote: > Baolin's patch Baolin writes many patches and patches have names, please use them! > on nr_migratepages was based on this one, a better fixup > for it might be below. Since before my patchset, compaction only deals with > order-0 pages. I don't understand what this means. The patchset you sent applies OK to mm-unstable so what else is there to do? > diff --git a/mm/compaction.c b/mm/compaction.c > index 01ec85cfd623f..e60135e2019d6 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -1798,7 +1798,7 @@ static struct folio *compaction_alloc(struct folio *src, unsigned long data) > dst = list_entry(cc->freepages.next, struct folio, lru); > list_del(&dst->lru); > cc->nr_freepages--; > - cc->nr_migratepages -= 1 << order; > + cc->nr_migratepages--; > > return dst; > } > @@ -1814,7 +1814,7 @@ static void compaction_free(struct folio *dst, unsigned long data) > > list_add(&dst->lru, &cc->freepages); > cc->nr_freepages++; > - cc->nr_migratepages += 1 << order; > + cc->nr_migratepages++; > }
On 19 Feb 2024, at 21:06, Andrew Morton wrote: > On Fri, 16 Feb 2024 12:04:28 -0500 Zi Yan <zi.yan@sent.com> wrote: > >> Baolin's patch > > Baolin writes many patches and patches have names, please use them! Sorry for not being specific. I mean this fixup: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=97f749c7c82f677f89bbf4f10de7816ce9b071fe to this patch: https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=ea87b0558293a5ad597bea606fe261f7b2650cda The patch was based on top of my early version of this patchset, thus uses "cc->nr_migratepages -= 1 << order;" and "cc->nr_migratepages += 1 << order;", but now it is applied before mine. The change should be "cc->nr_migratepages--;" and "cc->nr_migratepages++;", respectively. > >> on nr_migratepages was based on this one, a better fixup >> for it might be below. Since before my patchset, compaction only deals with >> order-0 pages. > > I don't understand what this means. The patchset you sent applies OK > to mm-unstable so what else is there to do? Your above fixup to Baolin's patch needs to be changed to the patch below and my "mm/compaction: add support for >0 order folio memory compaction" will need to be adjusted accordingly to be applied on top. Let me know if anything is unclear. >> diff --git a/mm/compaction.c b/mm/compaction.c >> index 01ec85cfd623f..e60135e2019d6 100644 >> --- a/mm/compaction.c >> +++ b/mm/compaction.c >> @@ -1798,7 +1798,7 @@ static struct folio *compaction_alloc(struct folio *src, unsigned long data) >> dst = list_entry(cc->freepages.next, struct folio, lru); >> list_del(&dst->lru); >> cc->nr_freepages--; >> - cc->nr_migratepages -= 1 << order; >> + cc->nr_migratepages--; >> >> return dst; >> } >> @@ -1814,7 +1814,7 @@ static void compaction_free(struct folio *dst, unsigned long data) >> >> list_add(&dst->lru, &cc->freepages); >> cc->nr_freepages++; >> - cc->nr_migratepages += 1 << order; >> + cc->nr_migratepages++; >> } -- Best Regards, Yan, Zi
On 2024/2/20 10:31, Zi Yan wrote: > On 19 Feb 2024, at 21:06, Andrew Morton wrote: > >> On Fri, 16 Feb 2024 12:04:28 -0500 Zi Yan <zi.yan@sent.com> wrote: >> >>> Baolin's patch >> >> Baolin writes many patches and patches have names, please use them! > Sorry for not being specific. I mean this fixup: > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=97f749c7c82f677f89bbf4f10de7816ce9b071fe > > to this patch: > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=ea87b0558293a5ad597bea606fe261f7b2650cda > > > The patch was based on top of my early version of this patchset, thus > uses "cc->nr_migratepages -= 1 << order;" and > "cc->nr_migratepages += 1 << order;", but now it is applied before > mine. The change should be "cc->nr_migratepages--;" and > "cc->nr_migratepages++;", respectively. > >> >>> on nr_migratepages was based on this one, a better fixup >>> for it might be below. Since before my patchset, compaction only deals with >>> order-0 pages. >> >> I don't understand what this means. The patchset you sent applies OK >> to mm-unstable so what else is there to do? > > Your above fixup to Baolin's patch needs to be changed to the patch below > and my "mm/compaction: add support for >0 order folio memory compaction" will > need to be adjusted accordingly to be applied on top. > > Let me know if anything is unclear. Hi Andrew, To avoid conflicts, you can drop these two patches, and I will send a new version with fixing the issue pointed by Vlastimilb on top of "mm/compaction: add support for >0 order folio memory compaction". https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=97f749c7c82f677f89bbf4f10de7816ce9b071fe https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=ea87b0558293a5ad597bea606fe261f7b2650cda
On Tue, 20 Feb 2024 11:00:39 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote: > > The patch was based on top of my early version of this patchset, thus > > uses "cc->nr_migratepages -= 1 << order;" and > > "cc->nr_migratepages += 1 << order;", but now it is applied before > > mine. The change should be "cc->nr_migratepages--;" and > > "cc->nr_migratepages++;", respectively. > > > >> > >>> on nr_migratepages was based on this one, a better fixup > >>> for it might be below. Since before my patchset, compaction only deals with > >>> order-0 pages. > >> > >> I don't understand what this means. The patchset you sent applies OK > >> to mm-unstable so what else is there to do? > > > > Your above fixup to Baolin's patch needs to be changed to the patch below > > and my "mm/compaction: add support for >0 order folio memory compaction" will > > need to be adjusted accordingly to be applied on top. > > > > Let me know if anything is unclear. > > Hi Andrew, > > To avoid conflicts, you can drop these two patches, and I will send a > new version with fixing the issue pointed by Vlastimilb on top of > "mm/compaction: add support for >0 order folio memory compaction". > > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=97f749c7c82f677f89bbf4f10de7816ce9b071fe > > https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=ea87b0558293a5ad597bea606fe261f7b2650cda Well I thought I'd fixed everything up 10 minutes ago. Please take a look at next mm-unstable.
On 2024/2/20 11:30, Andrew Morton wrote: > On Tue, 20 Feb 2024 11:00:39 +0800 Baolin Wang <baolin.wang@linux.alibaba.com> wrote: > >>> The patch was based on top of my early version of this patchset, thus >>> uses "cc->nr_migratepages -= 1 << order;" and >>> "cc->nr_migratepages += 1 << order;", but now it is applied before >>> mine. The change should be "cc->nr_migratepages--;" and >>> "cc->nr_migratepages++;", respectively. >>> >>>> >>>>> on nr_migratepages was based on this one, a better fixup >>>>> for it might be below. Since before my patchset, compaction only deals with >>>>> order-0 pages. >>>> >>>> I don't understand what this means. The patchset you sent applies OK >>>> to mm-unstable so what else is there to do? >>> >>> Your above fixup to Baolin's patch needs to be changed to the patch below >>> and my "mm/compaction: add support for >0 order folio memory compaction" will >>> need to be adjusted accordingly to be applied on top. >>> >>> Let me know if anything is unclear. >> >> Hi Andrew, >> >> To avoid conflicts, you can drop these two patches, and I will send a >> new version with fixing the issue pointed by Vlastimilb on top of >> "mm/compaction: add support for >0 order folio memory compaction". >> >> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=97f749c7c82f677f89bbf4f10de7816ce9b071fe >> >> https://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm.git/commit/?h=mm-everything-2024-02-16-01-35&id=ea87b0558293a5ad597bea606fe261f7b2650cda > > Well I thought I'd fixed everything up 10 minutes ago. Please take a > look at next mm-unstable. Sure. And I found a minor rebase error in the compaction_alloc() function while Zi Yan's original patch is correct. + cc->nr_freepages -= 1 << order; cc->nr_migratepages--; - - return dst; + return page_rmappable_folio(&dst->page); } should change to be: cc->nr_migratepages -= 1 << order;
diff --git a/mm/compaction.c b/mm/compaction.c index 01ec85cfd623f..e60135e2019d6 100644 --- a/mm/compaction.c +++ b/mm/compaction.c @@ -1798,7 +1798,7 @@ static struct folio *compaction_alloc(struct folio *src, unsigned long data) dst = list_entry(cc->freepages.next, struct folio, lru); list_del(&dst->lru); cc->nr_freepages--; - cc->nr_migratepages -= 1 << order; + cc->nr_migratepages--; return dst; } @@ -1814,7 +1814,7 @@ static void compaction_free(struct folio *dst, unsigned long data) list_add(&dst->lru, &cc->freepages); cc->nr_freepages++; - cc->nr_migratepages += 1 << order; + cc->nr_migratepages++; }