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 34783C43334 for ; Mon, 27 Jun 2022 09:49:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 69D958E0001; Mon, 27 Jun 2022 05:49:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64D1B6B0072; Mon, 27 Jun 2022 05:49:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 515A88E0001; Mon, 27 Jun 2022 05:49:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4233F6B0071 for ; Mon, 27 Jun 2022 05:49:34 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0E935336D7 for ; Mon, 27 Jun 2022 09:49:34 +0000 (UTC) X-FDA: 79623543468.12.E387589 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf28.hostedemail.com (Postfix) with ESMTP id D4B76C002A for ; Mon, 27 Jun 2022 09:49:31 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id E12D5CE13A2; Mon, 27 Jun 2022 09:49:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5F684C341C8; Mon, 27 Jun 2022 09:49:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656323367; bh=lJWk+ZM/8CuKn4jl1pGVvyZOF/4mTJyZtzz1FEVIr+A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t5vdQ9yyiawb2Yw1dKWIj339rFFdhRmHbHxXY7n7lXvF/7UcJnOJTOJoTDMAkWz83 ctHVP1qYmst9pxRIed942RMcgwUMIQNzgmRvSxp0nbx/+WJTsrF95NkfpQXUfBLIpg VeS6+9d7tRYKIc8RNsNfJIaXuyHJFd+CGR7PPyyqU/h1zR9uRZXZ8Ty99em1Dy0YJO r2sb5JCzu8RGkdIasEcUk5BqsVx3hOhK1U2ldALP1lzOG9OwVmCLTQKWw2wZYvo9pR ffMY+2h+oMCPJoak2gGFbPcMn2PIWFc2d4RyzEYds8cB1vVW2shlSlhn1TD6Tfy5Kj PWPMNPqpdDG7Q== Date: Mon, 27 Jun 2022 12:49:09 +0300 From: Mike Rapoport To: "guanghui.fgh" Cc: baolin.wang@linux.alibaba.com, catalin.marinas@arm.com, will@kernel.org, akpm@linux-foundation.org, david@redhat.com, jianyong.wu@arm.com, james.morse@arm.com, quic_qiancai@quicinc.com, christophe.leroy@csgroup.eu, jonathan@marek.ca, mark.rutland@arm.com, thunder.leizhen@huawei.com, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, geert+renesas@glider.be, ardb@kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] arm64: mm: fix linear mapping mem access performace degradation Message-ID: References: <1656241815-28494-1-git-send-email-guanghuifeng@linux.alibaba.com> <4d18d303-aeed-0beb-a8a4-32893f2d438d@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4d18d303-aeed-0beb-a8a4-32893f2d438d@linux.alibaba.com> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656323372; a=rsa-sha256; cv=none; b=e4LrueGauAjQjV/L/KnAUSs/TJGMveBjkINQJl/OZYBuyWJuoVmmCPZm7773EbvkuPiGcu uozQ9NVvVwYrWSwkgumfxOvFNxqJu3cNbghvqdO4QKcFhfMgjSBvH4erYUsp3mZHZSlt/A x5ylKk/UJj4QkLd95MZmaXumoMMZdes= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t5vdQ9yy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656323372; 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=2Yk8/D61yOSy4qyX9G1SqvCxKAYXT7HLa5y5gBFNiCQ=; b=FENC1grv8xqwb+8JDFK7M7G4qL29dHN2Cdjs1ZpdxT0jysX8REB2GrKEErg7E45C1mp7HQ 8dR1Eti6RSBqEMW35YFKVzeLej4WpVoJ7DdYyaFUuzG8EF8RUBXsuiV4U++aUKVCRfplxU PiG1Lt088MS3gZsJsExqNEOu8uE2XwM= X-Rspam-User: X-Stat-Signature: wyknx7xt9o6d95otman597e6pho3tytj X-Rspamd-Queue-Id: D4B76C002A Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=t5vdQ9yy; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf28.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org X-Rspamd-Server: rspam03 X-HE-Tag: 1656323371-321830 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: Please don't post HTML. On Mon, Jun 27, 2022 at 05:24:10PM +0800, guanghui.fgh wrote: > Thanks. > > 在 2022/6/27 14:34, Mike Rapoport 写道: > > On Sun, Jun 26, 2022 at 07:10:15PM +0800, Guanghui Feng wrote: > > The arm64 can build 2M/1G block/sectiion mapping. When using DMA/DMA32 zone > (enable crashkernel, disable rodata full, disable kfence), the mem_map will > use non block/section mapping(for crashkernel requires to shrink the region > in page granularity). But it will degrade performance when doing larging > continuous mem access in kernel(memcpy/memmove, etc). > > There are many changes and discussions: > commit 031495635b46 > commit 1a8e1cef7603 > commit 8424ecdde7df > commit 0a30c53573b0 > commit 2687275a5843 > > Please include oneline summary of the commit. (See section "Describe your > changes" in Documentation/process/submitting-patches.rst) > > OK, I will add oneline summary in the git commit messages. > > This patch changes mem_map to use block/section mapping with crashkernel. > Firstly, do block/section mapping(normally 2M or 1G) for all avail mem at > mem_map, reserve crashkernel memory. And then walking pagetable to split > block/section mapping to non block/section mapping(normally 4K) [[[only]]] > for crashkernel mem. > > This already happens when ZONE_DMA/ZONE_DMA32 are disabled. Please explain > why is it Ok to change the way the memory is mapped with > ZONE_DMA/ZONE_DMA32 enabled. > > In short: > > 1.building all avail mem with block/section mapping（normally 1G/2M） without > inspecting crashkernel > 2. Reserve crashkernel mem as same as previous doing > 3. only change the crashkernle mem mapping to normal mapping(normally 4k). > With this method, there are block/section mapping as more as possible. This does not answer the question why changing the way the memory is mapped when there is ZONE_DMA/DMA32 and crashkernel won't cause a regression. -- Sincerely yours, Mike.