From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Will Deacon <will.deacon@arm.com>
Cc: zhouxianrong@huawei.com, mark.rutland@arm.com,
wangkefeng.wang@huawei.com, srikar@linux.vnet.ibm.com,
Mi.Sophia.Wang@huawei.com, catalin.marinas@arm.com,
linux-mm@kvack.org, zhangshiming5@huawei.com,
frowand.list@gmail.com, zijun_hu@htc.com, jszhang@marvell.com,
won.ho.park@huawei.com, kuleshovmail@gmail.com,
devicetree@vger.kernel.org, chengang@emindsoft.com.cn,
zhouxiyu@huawei.com, tj@kernel.org, robh+dt@kernel.org,
weidu.du@huawei.com, linux-arm-kernel@lists.infradead.org,
ard.biesheuvel@linaro.org, steve.capper@arm.com,
linux-kernel@vger.kernel.org, joe@perches.com,
dennis.chen@arm.com, akpm@linux-foundation.org,
gkulkarni@caviumnetworks.com
Subject: Re: [PATCH] mm: free reserved area's memmap if possiable
Date: Mon, 13 Feb 2017 12:24:07 +0000 [thread overview]
Message-ID: <20170213122407.GX27312@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20170213121659.GM1512@arm.com>
On Mon, Feb 13, 2017 at 12:17:00PM +0000, Will Deacon wrote:
> Adding linux-arm-kernel and devicetree (look for "raw-pfn"), since this
> impacts directly on those.
>
> On Mon, Feb 13, 2017 at 08:02:29PM +0800, zhouxianrong@huawei.com wrote:
> > From: zhouxianrong <zhouxianrong@huawei.com>
> >
> > just like freeing no-map area's memmap we could free reserved
> > area's memmap as well only when user of reserved area indicate
> > that we can do this in dts or drivers. that is, user of reserved
> > area know how to use the reserved area who could not memblock_free
> > or free_reserved_xxx the reserved area and regard the area as raw
> > pfn usage. the patch supply a way to users who want to utilize the
> > memmap memory corresponding to raw pfn reserved areas as many as
> > possible.
>
> I don't really understand this. Can you point me at a specific use-case,
> please? Is CMA involved here?
You don't need "dt permission" to free the memmap page array for the
regions between memory areas. In fact, adding a DT property for that
goes against the "DT describes the hardware not the implementation"
requirement, since the memmap page array is a Linux implementation
detail.
32-bit ARM has been freeing the memmap page array between memory areas
for years since pre-DT days, and continues to do so. See
free_unused_memmap().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
WARNING: multiple messages have this Message-ID (diff)
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Will Deacon <will.deacon@arm.com>
Cc: zhouxianrong@huawei.com, mark.rutland@arm.com,
wangkefeng.wang@huawei.com, srikar@linux.vnet.ibm.com,
Mi.Sophia.Wang@huawei.com, catalin.marinas@arm.com,
linux-mm@kvack.org, zhangshiming5@huawei.com,
frowand.list@gmail.com, zijun_hu@htc.com, jszhang@marvell.com,
won.ho.park@huawei.com, kuleshovmail@gmail.com,
devicetree@vger.kernel.org, chengang@emindsoft.com.cn,
zhouxiyu@huawei.com, tj@kernel.org, robh+dt@kernel.org,
weidu.du@huawei.com, linux-arm-kernel@lists.infradead.org,
ard.biesheuvel@linaro.org, steve.capper@arm.com,
linux-kernel@vger.kernel.org, joe@perches.com,
dennis.chen@arm.com, akpm@linux-foundation.org,
gkulkarni@caviumnetworks.com
Subject: Re: [PATCH] mm: free reserved area's memmap if possiable
Date: Mon, 13 Feb 2017 12:24:07 +0000 [thread overview]
Message-ID: <20170213122407.GX27312@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20170213121659.GM1512@arm.com>
On Mon, Feb 13, 2017 at 12:17:00PM +0000, Will Deacon wrote:
> Adding linux-arm-kernel and devicetree (look for "raw-pfn"), since this
> impacts directly on those.
>
> On Mon, Feb 13, 2017 at 08:02:29PM +0800, zhouxianrong@huawei.com wrote:
> > From: zhouxianrong <zhouxianrong@huawei.com>
> >
> > just like freeing no-map area's memmap we could free reserved
> > area's memmap as well only when user of reserved area indicate
> > that we can do this in dts or drivers. that is, user of reserved
> > area know how to use the reserved area who could not memblock_free
> > or free_reserved_xxx the reserved area and regard the area as raw
> > pfn usage. the patch supply a way to users who want to utilize the
> > memmap memory corresponding to raw pfn reserved areas as many as
> > possible.
>
> I don't really understand this. Can you point me at a specific use-case,
> please? Is CMA involved here?
You don't need "dt permission" to free the memmap page array for the
regions between memory areas. In fact, adding a DT property for that
goes against the "DT describes the hardware not the implementation"
requirement, since the memmap page array is a Linux implementation
detail.
32-bit ARM has been freeing the memmap page array between memory areas
for years since pre-DT days, and continues to do so. See
free_unused_memmap().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mm: free reserved area's memmap if possiable
Date: Mon, 13 Feb 2017 12:24:07 +0000 [thread overview]
Message-ID: <20170213122407.GX27312@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20170213121659.GM1512@arm.com>
On Mon, Feb 13, 2017 at 12:17:00PM +0000, Will Deacon wrote:
> Adding linux-arm-kernel and devicetree (look for "raw-pfn"), since this
> impacts directly on those.
>
> On Mon, Feb 13, 2017 at 08:02:29PM +0800, zhouxianrong at huawei.com wrote:
> > From: zhouxianrong <zhouxianrong@huawei.com>
> >
> > just like freeing no-map area's memmap we could free reserved
> > area's memmap as well only when user of reserved area indicate
> > that we can do this in dts or drivers. that is, user of reserved
> > area know how to use the reserved area who could not memblock_free
> > or free_reserved_xxx the reserved area and regard the area as raw
> > pfn usage. the patch supply a way to users who want to utilize the
> > memmap memory corresponding to raw pfn reserved areas as many as
> > possible.
>
> I don't really understand this. Can you point me at a specific use-case,
> please? Is CMA involved here?
You don't need "dt permission" to free the memmap page array for the
regions between memory areas. In fact, adding a DT property for that
goes against the "DT describes the hardware not the implementation"
requirement, since the memmap page array is a Linux implementation
detail.
32-bit ARM has been freeing the memmap page array between memory areas
for years since pre-DT days, and continues to do so. See
free_unused_memmap().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2017-02-13 12:24 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 12:02 [PATCH] mm: free reserved area's memmap if possiable zhouxianrong
2017-02-13 12:02 ` zhouxianrong
2017-02-13 12:17 ` Will Deacon
2017-02-13 12:17 ` Will Deacon
2017-02-13 12:17 ` Will Deacon
2017-02-13 12:24 ` Russell King - ARM Linux [this message]
2017-02-13 12:24 ` Russell King - ARM Linux
2017-02-13 12:24 ` Russell King - ARM Linux
2017-02-13 14:54 ` kbuild test robot
2017-02-13 14:54 ` kbuild test robot
2017-02-14 6:53 ` zhouxianrong
2017-02-14 6:53 ` zhouxianrong at huawei.com
2017-02-14 6:53 ` zhouxianrong
2017-02-14 7:18 ` zhouxianrong
2017-02-14 7:18 ` zhouxianrong
2017-02-14 7:18 ` zhouxianrong
2017-02-14 9:03 ` Ard Biesheuvel
2017-02-14 9:03 ` Ard Biesheuvel
2017-02-14 9:03 ` Ard Biesheuvel
2017-02-15 1:44 ` zhouxianrong
2017-02-15 1:44 ` zhouxianrong
2017-02-15 1:44 ` zhouxianrong
2017-02-15 7:10 ` Ard Biesheuvel
2017-02-15 7:10 ` Ard Biesheuvel
2017-02-15 7:10 ` Ard Biesheuvel
2017-02-16 1:11 ` zhouxianrong
2017-02-16 1:11 ` zhouxianrong
2017-02-16 1:11 ` zhouxianrong
2017-03-01 10:41 ` Jisheng Zhang
2017-03-01 10:41 ` Jisheng Zhang
2017-03-01 10:41 ` Jisheng Zhang
2017-03-02 6:00 ` zhouxianrong
2017-03-02 6:00 ` zhouxianrong
2017-03-02 6:00 ` zhouxianrong
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=20170213122407.GX27312@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=Mi.Sophia.Wang@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=chengang@emindsoft.com.cn \
--cc=dennis.chen@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gkulkarni@caviumnetworks.com \
--cc=joe@perches.com \
--cc=jszhang@marvell.com \
--cc=kuleshovmail@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=srikar@linux.vnet.ibm.com \
--cc=steve.capper@arm.com \
--cc=tj@kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=weidu.du@huawei.com \
--cc=will.deacon@arm.com \
--cc=won.ho.park@huawei.com \
--cc=zhangshiming5@huawei.com \
--cc=zhouxianrong@huawei.com \
--cc=zhouxiyu@huawei.com \
--cc=zijun_hu@htc.com \
/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: link
Be 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.