From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com> To: Will Deacon <will@kernel.org>, Mike Rapoport <rppt@kernel.org> Cc: "catalin.marinas@arm.com" <catalin.marinas@arm.com>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "akpm@linux-foundation.org" <akpm@linux-foundation.org>, "anshuman.khandual@arm.com" <anshuman.khandual@arm.com>, Linuxarm <linuxarm@huawei.com> Subject: RE: [PATCH] arm64: mm: add support for memmap kernel parameters Date: Wed, 18 Nov 2020 20:25:56 +0000 [thread overview] Message-ID: <1d3780422d2648dfa80a6de87585819a@hisilicon.com> (raw) In-Reply-To: <20201118191528.GA2680@willie-the-truck> > -----Original Message----- > From: Will Deacon [mailto:will@kernel.org] > Sent: Thursday, November 19, 2020 8:15 AM > To: Mike Rapoport <rppt@kernel.org> > Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; > catalin.marinas@arm.com; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; akpm@linux-foundation.org; > anshuman.khandual@arm.com; Linuxarm <linuxarm@huawei.com> > 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
WARNING: multiple messages have this Message-ID (diff)
From: "Song Bao Hua (Barry Song)" <song.bao.hua@hisilicon.com> To: Will Deacon <will@kernel.org>, Mike Rapoport <rppt@kernel.org> Cc: "anshuman.khandual@arm.com" <anshuman.khandual@arm.com>, "catalin.marinas@arm.com" <catalin.marinas@arm.com>, Linuxarm <linuxarm@huawei.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "akpm@linux-foundation.org" <akpm@linux-foundation.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: RE: [PATCH] arm64: mm: add support for memmap kernel parameters Date: Wed, 18 Nov 2020 20:25:56 +0000 [thread overview] Message-ID: <1d3780422d2648dfa80a6de87585819a@hisilicon.com> (raw) In-Reply-To: <20201118191528.GA2680@willie-the-truck> > -----Original Message----- > From: Will Deacon [mailto:will@kernel.org] > Sent: Thursday, November 19, 2020 8:15 AM > To: Mike Rapoport <rppt@kernel.org> > Cc: Song Bao Hua (Barry Song) <song.bao.hua@hisilicon.com>; > catalin.marinas@arm.com; linux-arm-kernel@lists.infradead.org; > linux-kernel@vger.kernel.org; akpm@linux-foundation.org; > anshuman.khandual@arm.com; Linuxarm <linuxarm@huawei.com> > 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
next prev parent reply other threads:[~2020-11-18 20:26 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-18 6:33 [PATCH] arm64: mm: add support for memmap kernel parameters Barry Song 2020-11-18 6:33 ` Barry Song 2020-11-18 17:38 ` Mike Rapoport 2020-11-18 17:38 ` Mike Rapoport 2020-11-18 19:15 ` Will Deacon 2020-11-18 19:15 ` Will Deacon 2020-11-18 20:25 ` Song Bao Hua (Barry Song) [this message] 2020-11-18 20:25 ` Song Bao Hua (Barry Song) 2020-11-18 22:38 ` Ard Biesheuvel 2020-11-18 22:38 ` Ard Biesheuvel 2020-11-18 23:55 ` Song Bao Hua (Barry Song) 2020-11-18 23:55 ` Song Bao Hua (Barry Song) 2020-11-19 7:57 ` Mike Rapoport 2020-11-19 7:57 ` Mike Rapoport 2020-11-19 8:37 ` Song Bao Hua (Barry Song) 2020-11-19 8:37 ` Song Bao Hua (Barry Song)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1d3780422d2648dfa80a6de87585819a@hisilicon.com \ --to=song.bao.hua@hisilicon.com \ --cc=akpm@linux-foundation.org \ --cc=anshuman.khandual@arm.com \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linuxarm@huawei.com \ --cc=rppt@kernel.org \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.