From patchwork Wed Feb 23 04:30:32 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Zi Yan X-Patchwork-Id: 1596493 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=sent.com header.i=@sent.com header.a=rsa-sha256 header.s=fm2 header.b=moTacVGx; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=Os0hmMfz; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org (client-ip=2404:9400:2:0:216:3eff:fee1:b9f1; helo=lists.ozlabs.org; envelope-from=linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org; receiver=) Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2404:9400:2:0:216:3eff:fee1:b9f1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4K3NR96qCNz9sG2 for ; Wed, 23 Feb 2022 15:31:49 +1100 (AEDT) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4K3NR46QVKz3cT8 for ; Wed, 23 Feb 2022 15:31:44 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=sent.com header.i=@sent.com header.a=rsa-sha256 header.s=fm2 header.b=moTacVGx; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=Os0hmMfz; dkim-atps=neutral X-Original-To: linuxppc-dev@lists.ozlabs.org Delivered-To: linuxppc-dev@lists.ozlabs.org Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=sent.com (client-ip=66.111.4.224; helo=new2-smtp.messagingengine.com; envelope-from=zi.yan@sent.com; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=sent.com header.i=@sent.com header.a=rsa-sha256 header.s=fm2 header.b=moTacVGx; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm2 header.b=Os0hmMfz; dkim-atps=neutral Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4K3NQ242sRz3bNs for ; Wed, 23 Feb 2022 15:30:50 +1100 (AEDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 42B94580055; Tue, 22 Feb 2022 23:30:45 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 22 Feb 2022 23:30:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sent.com; h=cc :cc:content-transfer-encoding:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:reply-to:sender:subject :subject:to:to; s=fm2; bh=ETC2AAf47GJ+iGkmCj4k43U6GvDQMOzkmXEXAA ZFQiE=; b=moTacVGxwQE7c3T9nkxC0XjeIrAoEmvXOQC6Eo3J/3XXfZ26exoKAT /QsARQD9yWNIh3jhTbxVulurxuo/F6T30nnZylLM6Dohzj7dnHCSbD4BmmS4zRio yR8K4wAJb76Rstdbh1K6WwR4ZE80ibQLj7S0hmS24CPmlcDOUP/MDVVxy1uJkQjA BahzsRtK5VLT8eeGTx9Ni+YN+fzMloOa1Vz4jSxEq542dW5ZKPZNB3kT7JVK0+Sl BFfBUVn4ESU+tSGh+uQbnlW12UyImkmR30R8Yri7sBxl9/TvLjQmpu+1G1XtQLi9 taOqjBQzYJmbwvBTR2VcnlETcaOgGKiw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding:date:date :from:from:in-reply-to:message-id:mime-version:reply-to:reply-to :sender:subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ETC2AAf47GJ+iGkmCj4k43U6GvDQM OzkmXEXAAZFQiE=; b=Os0hmMfzfgNY/B8oGtvV6Jd9ITb3gcMUIKPpKDNXNoU2N Cyt23PLwW1ebDpqR9nZ9SshDsT8+3kJXAhllhWPX7d5WRbw1sEy4rKaf/6yuG9SN hEcbE+u8GPX/+GWlQa8r7oqN2KAb1S9BdtunW6oAW9NL0T8tz93HGOS8m8zK+Yul +cB/OGwzOFvytXnMOhFPyKiLJR/bLQigqfq1UBlWTLah2QmxGA/sH3ypL1HpOkAS oJvGmAYN3487umX+YXwjj9xU65Ke57gK03Fa7LOhV+JY1dzmpEetKK1cjzZ/Xv7/ yhfjSKAXsN4wsyKJEq8NeTVivVednNXUVTEIyD3Qw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrkeelgdejtdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkofhrggfgsedtqhertdertddtnecuhfhrohhmpegkihcujggrnhcu oeiiihdrhigrnhesshgvnhhtrdgtohhmqeenucggtffrrghtthgvrhhnpeetieeitdejgf fhfeeukeejvdeufedtvddulefhteduffeigfefteehgefhvdegudenucffohhmrghinhep khgvrhhnvghlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepiihirdihrghnsehsvghnthdrtghomh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 22 Feb 2022 23:30:43 -0500 (EST) From: Zi Yan To: David Hildenbrand , linux-mm@kvack.org Subject: [PATCH v6 0/5] Use pageblock_order for cma and alloc_contig_range alignment. Date: Tue, 22 Feb 2022 23:30:32 -0500 Message-Id: <20220223043037.715205-1-zi.yan@sent.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Zi Yan Cc: Mel Gorman , Zi Yan , Oscar Salvador , Robin Murphy , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Mike Rapoport , Eric Ren , virtualization@lists.linux-foundation.org, linuxppc-dev@lists.ozlabs.org, Christoph Hellwig , Vlastimil Babka , Marek Szyprowski Errors-To: linuxppc-dev-bounces+incoming=patchwork.ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" From: Zi Yan Hi all, This patchset tries to remove the MAX_ORDER-1 alignment requirement for CMA and alloc_contig_range(). It prepares for my upcoming changes to make MAX_ORDER adjustable at boot time[1]. It is on top of mmotm-2022-02-14-17-46. Changelog === V6 --- 1. Resolved compilation error/warning reported by kernel test robot. 2. Tried to solve the coding concerns from Christophe Leroy. 3. Shortened lengthy lines (pointed out by Christoph Hellwig). V5 --- 1. Moved isolation address alignment handling in start_isolate_page_range(). 2. Rewrote and simplified how alloc_contig_range() works at pageblock granularity (Patch 3). Only two pageblock migratetypes need to be saved and restored. start_isolate_page_range() might need to migrate pages in this version, but it prevents the caller from worrying about max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages) alignment after the page range is isolated. V4 --- 1. Dropped two irrelevant patches on non-lru compound page handling, as it is not supported upstream. 2. Renamed migratetype_has_fallback() to migratetype_is_mergeable(). 3. Always check whether two pageblocks can be merged in __free_one_page() when order is >= pageblock_order, as the case (not mergeable pageblocks are isolated, CMA, and HIGHATOMIC) becomes more common. 3. Moving has_unmovable_pages() is now a separate patch. 4. Removed MAX_ORDER-1 alignment requirement in the comment in virtio_mem code. Description === The MAX_ORDER - 1 alignment requirement comes from that alloc_contig_range() isolates pageblocks to remove free memory from buddy allocator but isolating only a subset of pageblocks within a page spanning across multiple pageblocks causes free page accounting issues. Isolated page might not be put into the right free list, since the code assumes the migratetype of the first pageblock as the whole free page migratetype. This is based on the discussion at [2]. To remove the requirement, this patchset: 1. isolates pages at pageblock granularity instead of max(MAX_ORDER_NR_PAEGS, pageblock_nr_pages); 2. splits free pages across the specified range or migrates in-use pages across the specified range then splits the freed page to avoid free page accounting issues (it happens when multiple pageblocks within a single page have different migratetypes); 3. only checks unmovable pages within the range instead of MAX_ORDER - 1 aligned range during isolation to avoid alloc_contig_range() failure when pageblocks within a MAX_ORDER - 1 aligned range are allocated separately. 4. returns pages not in the range as it did before. One optimization might come later: 1. make MIGRATE_ISOLATE a separate bit to be able to restore the original migratetypes when isolation fails in the middle of the range. Feel free to give comments and suggestions. Thanks. [1] https://lore.kernel.org/linux-mm/20210805190253.2795604-1-zi.yan@sent.com/ [2] https://lore.kernel.org/linux-mm/d19fb078-cb9b-f60f-e310-fdeea1b947d2@redhat.com/ Zi Yan (5): mm: page_isolation: move has_unmovable_pages() to mm/page_isolation.c mm: page_isolation: check specified range for unmovable pages mm: make alloc_contig_range work at pageblock granularity mm: cma: use pageblock_order as the single alignment drivers: virtio_mem: use pageblock size as the minimum virtio_mem size. drivers/virtio/virtio_mem.c | 6 +- include/linux/cma.h | 4 +- include/linux/mmzone.h | 5 +- include/linux/page-isolation.h | 14 +- mm/internal.h | 6 + mm/memory_hotplug.c | 3 +- mm/page_alloc.c | 246 +++++++-------------------- mm/page_isolation.c | 296 +++++++++++++++++++++++++++++++-- 8 files changed, 367 insertions(+), 213 deletions(-)