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=-3.7 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 A2D79C5519F for ; Wed, 18 Nov 2020 20:26:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4A8FE2145D for ; Wed, 18 Nov 2020 20:26:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726641AbgKRUZ7 convert rfc822-to-8bit (ORCPT ); Wed, 18 Nov 2020 15:25:59 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:2066 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbgKRUZ6 (ORCPT ); Wed, 18 Nov 2020 15:25:58 -0500 Received: from DGGEMM405-HUB.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4CbvSm6hTjzVpDN; Thu, 19 Nov 2020 04:25:28 +0800 (CST) Received: from dggemi760-chm.china.huawei.com (10.1.198.146) by DGGEMM405-HUB.china.huawei.com (10.3.20.213) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 19 Nov 2020 04:25:56 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggemi760-chm.china.huawei.com (10.1.198.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 19 Nov 2020 04:25:56 +0800 Received: from dggemi761-chm.china.huawei.com ([10.9.49.202]) by dggemi761-chm.china.huawei.com ([10.9.49.202]) with mapi id 15.01.1913.007; Thu, 19 Nov 2020 04:25:56 +0800 From: "Song Bao Hua (Barry Song)" To: Will Deacon , Mike Rapoport CC: "catalin.marinas@arm.com" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "anshuman.khandual@arm.com" , Linuxarm Subject: RE: [PATCH] arm64: mm: add support for memmap kernel parameters Thread-Topic: [PATCH] arm64: mm: add support for memmap kernel parameters Thread-Index: AQHWvXVLtrpWHgsWH0upIuwmJUX89KnNolcAgAAa/ICAAJI6cA== Date: Wed, 18 Nov 2020 20:25:56 +0000 Message-ID: <1d3780422d2648dfa80a6de87585819a@hisilicon.com> References: <20201118063314.22940-1-song.bao.hua@hisilicon.com> <20201118173854.GA8537@kernel.org> <20201118191528.GA2680@willie-the-truck> In-Reply-To: <20201118191528.GA2680@willie-the-truck> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.201.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > -----Original Message----- > From: Will Deacon [mailto:will@kernel.org] > Sent: Thursday, November 19, 2020 8:15 AM > To: Mike Rapoport > Cc: Song Bao Hua (Barry Song) ; > catalin.marinas@arm.com; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; akpm@linux-foundation.org; > anshuman.khandual@arm.com; Linuxarm > Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters > > On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote: > > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote: > > > memmap should be an useful kernel parameter which has been supported > by > > > x86, mips and xtensa. > > > > Why is this parameter should be useful for ARM64? > > My understanding is that it is required only to work around really > > broken bootloaders, isn't it? > 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 > Agreed, I can't see this being something we really want to support. If it > turns out that it is generally useful, then the implementation should > probably be somewhere outside of arch/ where I don't have to look at it :) > What stops this becoming common code is that each platform has different ways and boot sequences to populate memblock. For example, on Arm64, while early_param is populated, dt has populated memblock before that. Other platforms might been much different. > Will Thanks Barry 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 E57C3C5519F for ; Wed, 18 Nov 2020 20:27:34 +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 396C921D1A for ; Wed, 18 Nov 2020 20:27:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="Pnfia9yG" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 396C921D1A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=hisilicon.com 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:MIME-Version:In-Reply-To:References:Message-ID:Date: Subject:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RvZR1BvY/ksol2tHsEIHRIm0DuLe6bygFUMKP8S1O/o=; b=Pnfia9yGHylNeCbIX8vST1Bmo bZvQiZfiZ5+tl9KO/vG7Ch4MmY2kmZTC9K3iaJX834GNmzm+tT30/CEDd24nRRGc2zVSMJqyUFKXx JlcObTJQIRTIN+Z6BYN3MK1q1MoQNhYRVkj3XAO/kz4W+jTVSdF84m61NbwHyJeR4nl5yz/8uzN0x 8e3aD6yw4CQJiQUyx09tMn4sXP6auUVnecjtnJuDApYjCohn2g8aWzFqg8HRhy9ymihUtKsi+AqOW 4wLZ5bFecqQfsXy7xnbVRUj6sKPFcM0BZjUMNSan6Y0IDdY88hZcTQmEBvBv6kmkkDsN8dfZoLmKV uG90EqkrQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfU1p-0004Q0-JH; Wed, 18 Nov 2020 20:26:09 +0000 Received: from szxga01-in.huawei.com ([45.249.212.187]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kfU1m-0004PY-FZ for linux-arm-kernel@lists.infradead.org; Wed, 18 Nov 2020 20:26:08 +0000 Received: from DGGEMM405-HUB.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4CbvSm6hTjzVpDN; Thu, 19 Nov 2020 04:25:28 +0800 (CST) Received: from dggemi760-chm.china.huawei.com (10.1.198.146) by DGGEMM405-HUB.china.huawei.com (10.3.20.213) with Microsoft SMTP Server (TLS) id 14.3.487.0; Thu, 19 Nov 2020 04:25:56 +0800 Received: from dggemi761-chm.china.huawei.com (10.1.198.147) by dggemi760-chm.china.huawei.com (10.1.198.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Thu, 19 Nov 2020 04:25:56 +0800 Received: from dggemi761-chm.china.huawei.com ([10.9.49.202]) by dggemi761-chm.china.huawei.com ([10.9.49.202]) with mapi id 15.01.1913.007; Thu, 19 Nov 2020 04:25:56 +0800 From: "Song Bao Hua (Barry Song)" To: Will Deacon , Mike Rapoport Subject: RE: [PATCH] arm64: mm: add support for memmap kernel parameters Thread-Topic: [PATCH] arm64: mm: add support for memmap kernel parameters Thread-Index: AQHWvXVLtrpWHgsWH0upIuwmJUX89KnNolcAgAAa/ICAAJI6cA== Date: Wed, 18 Nov 2020 20:25:56 +0000 Message-ID: <1d3780422d2648dfa80a6de87585819a@hisilicon.com> References: <20201118063314.22940-1-song.bao.hua@hisilicon.com> <20201118173854.GA8537@kernel.org> <20201118191528.GA2680@willie-the-truck> In-Reply-To: <20201118191528.GA2680@willie-the-truck> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.126.201.71] MIME-Version: 1.0 X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201118_152607_022634_DC3ED8FC X-CRM114-Status: GOOD ( 19.97 ) 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" , Linuxarm , "linux-kernel@vger.kernel.org" , "akpm@linux-foundation.org" , "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 > -----Original Message----- > From: Will Deacon [mailto:will@kernel.org] > Sent: Thursday, November 19, 2020 8:15 AM > To: Mike Rapoport > Cc: Song Bao Hua (Barry Song) ; > catalin.marinas@arm.com; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; akpm@linux-foundation.org; > anshuman.khandual@arm.com; Linuxarm > Subject: Re: [PATCH] arm64: mm: add support for memmap kernel parameters > > On Wed, Nov 18, 2020 at 07:38:54PM +0200, Mike Rapoport wrote: > > On Wed, Nov 18, 2020 at 07:33:14PM +1300, Barry Song wrote: > > > memmap should be an useful kernel parameter which has been supported > by > > > x86, mips and xtensa. > > > > Why is this parameter should be useful for ARM64? > > My understanding is that it is required only to work around really > > broken bootloaders, isn't it? > 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 > Agreed, I can't see this being something we really want to support. If it > turns out that it is generally useful, then the implementation should > probably be somewhere outside of arch/ where I don't have to look at it :) > What stops this becoming common code is that each platform has different ways and boot sequences to populate memblock. For example, on Arm64, while early_param is populated, dt has populated memblock before that. Other platforms might been much different. > Will Thanks Barry _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel