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 X-Spam-Level: X-Spam-Status: No, score=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 582A2C388F9 for ; Thu, 19 Nov 2020 07:57:53 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E990A246BB for ; Thu, 19 Nov 2020 07:57:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BrazXTMr" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726458AbgKSH5c (ORCPT ); Thu, 19 Nov 2020 02:57:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:40086 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725877AbgKSH5b (ORCPT ); Thu, 19 Nov 2020 02:57:31 -0500 Received: from kernel.org (unknown [77.125.7.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 418E52220B; Thu, 19 Nov 2020 07:57:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605772650; bh=gOXz1u76tWhkvKp6lt1lxVqTdmPvAJOuOUyzXoABdes=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BrazXTMrRpQpk3FBERDS4HgvufWUdlOuxH113+vXxRKCyNjPiwCeJ8499H4Ot3JWk xTAEuBPVpEglWKCNb36P/Hlu63w2G19v65+QiqIwdJ8NgP/QO9ylojUT/HuKKUKNXl mVaeJ74KLAyTUymZt1ZzNTR9XmHV2pE+3d6+H4wg= Date: Thu, 19 Nov 2020 09:57:22 +0200 From: Mike Rapoport To: "Song Bao Hua (Barry Song)" Cc: Ard Biesheuvel , Will Deacon , "anshuman.khandual@arm.com" , "catalin.marinas@arm.com" , Linuxarm , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "linux-arm-kernel@lists.infradead.org" Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters Message-ID: <20201119075722.GC8537@kernel.org> References: <20201118063314.22940-1-song.bao.hua@hisilicon.com> <20201118173854.GA8537@kernel.org> <20201118191528.GA2680@willie-the-truck> <1d3780422d2648dfa80a6de87585819a@hisilicon.com> <0a1de2555ed2458d97e5c79929f74380@hisilicon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a1de2555ed2458d97e5c79929f74380@hisilicon.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Nov 18, 2020 at 11:55:33PM +0000, Song Bao Hua (Barry Song) wrote: > > From: Ard Biesheuvel [mailto:ardb@kernel.org] > > > > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song) > > wrote: > > > > > > Good question. Originally I wrote this patch to debug and verify the > > vmemmap > > > leak issue reported in this patch: > > > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that > > define VMEMMAP > > > > > https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@ > > huawei.com/ > > > I don't have a machine which really has holes in memory_section to debug, > > but memmap > > > can help. With memmap, I could specified a machine with various holds in > > mem_sections. > > > > > > After that, I figured out this is not only useful for debugging purpose. it can > > have some real user cases. > > > For example: > > > > > > 1. DAX on DRAM. > > > kernel parameter memmap=XG!YG specifies a range of RAM to emulate > > pmem. Then we are able > > > to run DAX and filesystem on top of it. Furthermore, this will probably also > > benefit the case > > > this big patchset wants to "fix" via direct access to memory: > > > > > https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T > > /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > > > as the comments have clearly shown. > > > > > > 2. reserve some memory for userspace to manage via /dev/mem > > > > > > > Apologies for the bluntness, but what you are saying here is that you > > need a hack to pile those other hacks onto. > > > > Currently, we use the NOMAP attribute in memblock to describe memory > > that is omitted from the direct map. Removing memory from memblock > > entirely also strips it of this annotation, which means that > > phys_mem_access_prot() will identify it as device memory not DRAM, and > > use the wrong attributes when using /dev/mem. > > > > There are likely other places where this distinction matters, and so I > > am not buying the justification that we can make meaningful use of > > this memory in the general case, and anything that relies on it will > > be fragile, and probably only limited to very specific debug > > scenarios. > > Yep. originally I did that for debugging purpose to emulate a machine with > some holes in mem_section. I guess it should be also useful to other people > if they need the same thing for debugging. > > > > > So I don't think we should merge this. > > It should be in the same situation for other platforms like x86, mips and xtensa > but they have enabled this kernel parameter. I didn't check mips and xtensa, but x86 carries this from nineties when they needed a way to work around broken BIOSes. I really doubt x86 maintainers would merge such feature these days. > maybe the emulated pmem by DRAM is an useful scenario other than debugging. > > Later, https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > might be able to use this parameter. Using kernel parameters to describe complex memory configuration does not seem scalable and maintainable. A simple mem=X should be enough for features like dmemfs to start with and if/when anything more complex will be required I doubt a kernel parameter would fit that purpose. Another thing as as soon as we expose this parameter to the user we'd have to make sure they can always get the memory layout they defined with it. Keeping the kernel parameter in sync with other means of memory detection would complicate things on both sides. Ard mentioned NOMAP property, there may be some NUMA considerations that could create a conflict between what user asked and what is possible and other things that may come up in the future. > Anyway, I don't mind keeping it local for debugging at this stage and waiting for a > more convincing use case. > > Thanks > Barry > -- Sincerely yours, Mike. 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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 06390C2D0E4 for ; Thu, 19 Nov 2020 07:59:01 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 73CCE2223F for ; Thu, 19 Nov 2020 07:59:00 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="bgQLhN31"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="BrazXTMr" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 73CCE2223F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=oaF+cUQ4kVKOXRGr1vOpHwHsLbaylOVz5DdRMQ+eewM=; b=bgQLhN31m8A/IL5jGYyR88Ewy 7UT22dhpXcV3T7oxzhGowY4ThsBiJnQYFiz2tUpO97H+9De0uRL0j5JdKXwVHMo4wDbALSNZKyUhm G3E/pdpptTnWcdYm19Rb0Ctj/+nCxufWHbO0V15lYcbDKEFVfqYWVTvgRykQLmETyAD1xxZJj/24p vfOti0wxhP/5FLjYJ1IB9DmtRGUi4tivZrUPunxbC3tJ0zeOf9VwSPh41GRWhdxEZo9gkJ1Xd+s89 LM29sTr/ZQZUqMipg54as/NGNyGRk1A98+BwQlTy0QfOnEgIiZtVe5gWlHMXCsFEuy0/k55IZYltR 0hSVnwTIA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfeow-0002b6-T2; Thu, 19 Nov 2020 07:57:34 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfeou-0002Zl-1e for linux-arm-kernel@lists.infradead.org; Thu, 19 Nov 2020 07:57:33 +0000 Received: from kernel.org (unknown [77.125.7.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 418E52220B; Thu, 19 Nov 2020 07:57:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605772650; bh=gOXz1u76tWhkvKp6lt1lxVqTdmPvAJOuOUyzXoABdes=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BrazXTMrRpQpk3FBERDS4HgvufWUdlOuxH113+vXxRKCyNjPiwCeJ8499H4Ot3JWk xTAEuBPVpEglWKCNb36P/Hlu63w2G19v65+QiqIwdJ8NgP/QO9ylojUT/HuKKUKNXl mVaeJ74KLAyTUymZt1ZzNTR9XmHV2pE+3d6+H4wg= Date: Thu, 19 Nov 2020 09:57:22 +0200 From: Mike Rapoport To: "Song Bao Hua (Barry Song)" Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters Message-ID: <20201119075722.GC8537@kernel.org> References: <20201118063314.22940-1-song.bao.hua@hisilicon.com> <20201118173854.GA8537@kernel.org> <20201118191528.GA2680@willie-the-truck> <1d3780422d2648dfa80a6de87585819a@hisilicon.com> <0a1de2555ed2458d97e5c79929f74380@hisilicon.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <0a1de2555ed2458d97e5c79929f74380@hisilicon.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201119_025732_293495_F42FA2E8 X-CRM114-Status: GOOD ( 43.55 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: "anshuman.khandual@arm.com" , "catalin.marinas@arm.com" , "linux-kernel@vger.kernel.org" , Linuxarm , "akpm@linux-foundation.org" , Will Deacon , Ard Biesheuvel , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 18, 2020 at 11:55:33PM +0000, Song Bao Hua (Barry Song) wrote: > > From: Ard Biesheuvel [mailto:ardb@kernel.org] > > > > On Wed, 18 Nov 2020 at 21:27, Song Bao Hua (Barry Song) > > wrote: > > > > > > Good question. Originally I wrote this patch to debug and verify the > > vmemmap > > > leak issue reported in this patch: > > > [PATCH v2] arm64: mm: free unused memmap for sparse memory model that > > define VMEMMAP > > > > > https://lore.kernel.org/linux-arm-kernel/20200812010655.96339-1-liwei213@ > > huawei.com/ > > > I don't have a machine which really has holes in memory_section to debug, > > but memmap > > > can help. With memmap, I could specified a machine with various holds in > > mem_sections. > > > > > > After that, I figured out this is not only useful for debugging purpose. it can > > have some real user cases. > > > For example: > > > > > > 1. DAX on DRAM. > > > kernel parameter memmap=XG!YG specifies a range of RAM to emulate > > pmem. Then we are able > > > to run DAX and filesystem on top of it. Furthermore, this will probably also > > benefit the case > > > this big patchset wants to "fix" via direct access to memory: > > > > > https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T > > /#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > > > as the comments have clearly shown. > > > > > > 2. reserve some memory for userspace to manage via /dev/mem > > > > > > > Apologies for the bluntness, but what you are saying here is that you > > need a hack to pile those other hacks onto. > > > > Currently, we use the NOMAP attribute in memblock to describe memory > > that is omitted from the direct map. Removing memory from memblock > > entirely also strips it of this annotation, which means that > > phys_mem_access_prot() will identify it as device memory not DRAM, and > > use the wrong attributes when using /dev/mem. > > > > There are likely other places where this distinction matters, and so I > > am not buying the justification that we can make meaningful use of > > this memory in the general case, and anything that relies on it will > > be fragile, and probably only limited to very specific debug > > scenarios. > > Yep. originally I did that for debugging purpose to emulate a machine with > some holes in mem_section. I guess it should be also useful to other people > if they need the same thing for debugging. > > > > > So I don't think we should merge this. > > It should be in the same situation for other platforms like x86, mips and xtensa > but they have enabled this kernel parameter. I didn't check mips and xtensa, but x86 carries this from nineties when they needed a way to work around broken BIOSes. I really doubt x86 maintainers would merge such feature these days. > maybe the emulated pmem by DRAM is an useful scenario other than debugging. > > Later, https://lore.kernel.org/lkml/cover.1602093760.git.yuleixzhang@tencent.com/T/#m1a77074b8e1dadc590a5f45a52d9c3cda69c0780 > might be able to use this parameter. Using kernel parameters to describe complex memory configuration does not seem scalable and maintainable. A simple mem=X should be enough for features like dmemfs to start with and if/when anything more complex will be required I doubt a kernel parameter would fit that purpose. Another thing as as soon as we expose this parameter to the user we'd have to make sure they can always get the memory layout they defined with it. Keeping the kernel parameter in sync with other means of memory detection would complicate things on both sides. Ard mentioned NOMAP property, there may be some NUMA considerations that could create a conflict between what user asked and what is possible and other things that may come up in the future. > Anyway, I don't mind keeping it local for debugging at this stage and waiting for a > more convincing use case. > > Thanks > Barry > -- Sincerely yours, Mike. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel