From: Tejun Heo <tj@kernel.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Date: Sat, 29 Jun 2013 10:57:43 -0700 [thread overview]
Message-ID: <20130629175743.GA382@mtj.dyndns.org> (raw)
In-Reply-To: <20130629172123.GA3353@n2100.arm.linux.org.uk>
( Expanding cc list, original thread is at
http://thread.gmane.org/gmane.linux.kernel/1518046 )
Hello,
On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more. This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
>
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM. As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.
Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....
Given that still about half of the archs aren't using memblock yet, I
think there are three options.
1. Converting all bootmem interface to use physaddr_t. But that's
what memblock is.
2. Introducing new interface. Easier right now but the danger there
is that it might end up duplicating most of alloc_bootmem()
interface anyway and we'll have yet another variant of early mem
allocator to enjoy.
3. Make all generic code use memblock interface instead of bootmem and
implement memblock wrapper on archs which don't use memblock yet.
We'll probably need to sort out different combinations of
HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is
the most future proof way. While it adds new memblock interface
built on top of bootmem, it would also allow removing the bootmem
interface built on top of memblock - ie. nobootmem.c, which
probably is what we should have done from the beginning.
What do you guys think?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Ingo Molnar <mingo@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
"David S. Miller" <davem@davemloft.net>,
sparclinux@vger.kernel.org, Sam Ravnborg <sam@ravnborg.org>,
linux-arch@vger.kernel.org
Subject: Re: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Date: Sat, 29 Jun 2013 17:57:43 +0000 [thread overview]
Message-ID: <20130629175743.GA382@mtj.dyndns.org> (raw)
In-Reply-To: <20130629172123.GA3353@n2100.arm.linux.org.uk>
( Expanding cc list, original thread is at
http://thread.gmane.org/gmane.linux.kernel/1518046 )
Hello,
On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more. This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
>
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM. As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.
Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....
Given that still about half of the archs aren't using memblock yet, I
think there are three options.
1. Converting all bootmem interface to use physaddr_t. But that's
what memblock is.
2. Introducing new interface. Easier right now but the danger there
is that it might end up duplicating most of alloc_bootmem()
interface anyway and we'll have yet another variant of early mem
allocator to enjoy.
3. Make all generic code use memblock interface instead of bootmem and
implement memblock wrapper on archs which don't use memblock yet.
We'll probably need to sort out different combinations of
HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is
the most future proof way. While it adds new memblock interface
built on top of bootmem, it would also allow removing the bootmem
interface built on top of memblock - ie. nobootmem.c, which
probably is what we should have done from the beginning.
What do you guys think?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: tj@kernel.org (Tejun Heo)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM
Date: Sat, 29 Jun 2013 10:57:43 -0700 [thread overview]
Message-ID: <20130629175743.GA382@mtj.dyndns.org> (raw)
In-Reply-To: <20130629172123.GA3353@n2100.arm.linux.org.uk>
( Expanding cc list, original thread is at
http://thread.gmane.org/gmane.linux.kernel/1518046 )
Hello,
On Sat, Jun 29, 2013 at 06:21:24PM +0100, Russell King - ARM Linux wrote:
> Unfortunately, that has not been true on ARM - it's very common for
> there to be an offset on physical memory, sometimes of the order of
> 3GB or more. This is because on reset, ARMs start executing the code
> at physical address zero, which therefore can't be RAM - and there's
> a desire to avoid complex switching games in hardware to temporarily
> map ROM there instead of RAM.
>
> On these SoCs which Santosh is working on, the main physical memory
> mapping is above 4GB, with just a small alias below 4GB to allow the
> system to boot without the MMU being on, as they may have more than
> 4GB of RAM. As I understand it, the small alias below 4GB is not
> suitable for use as a "lowmem" mapping.
Ah, okay, so the @limit which is in physical address can be over 4GB
even for lowmem mappings and alloc_bootmem takes them in ulongs,
urghhh....
Given that still about half of the archs aren't using memblock yet, I
think there are three options.
1. Converting all bootmem interface to use physaddr_t. But that's
what memblock is.
2. Introducing new interface. Easier right now but the danger there
is that it might end up duplicating most of alloc_bootmem()
interface anyway and we'll have yet another variant of early mem
allocator to enjoy.
3. Make all generic code use memblock interface instead of bootmem and
implement memblock wrapper on archs which don't use memblock yet.
We'll probably need to sort out different combinations of
HAVE_MEMBLOCK and NO_BOOTMEM. If this is doable, it probably is
the most future proof way. While it adds new memblock interface
built on top of bootmem, it would also allow removing the bootmem
interface built on top of memblock - ie. nobootmem.c, which
probably is what we should have done from the beginning.
What do you guys think?
Thanks.
--
tejun
next prev parent reply other threads:[~2013-06-29 17:57 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-29 1:01 [PATCH] WIP: HACK: LPAE, BOOTMEM and NO_BOOTMEM Santosh Shilimkar
2013-06-29 1:01 ` Santosh Shilimkar
2013-06-29 15:29 ` Tejun Heo
2013-06-29 15:29 ` Tejun Heo
2013-06-29 17:21 ` Russell King - ARM Linux
2013-06-29 17:21 ` Russell King - ARM Linux
2013-06-29 17:57 ` Tejun Heo [this message]
2013-06-29 17:57 ` Tejun Heo
2013-06-29 17:57 ` Tejun Heo
2013-06-29 18:23 ` H. Peter Anvin
2013-06-29 18:23 ` H. Peter Anvin
2013-06-29 18:23 ` H. Peter Anvin
2013-06-29 18:23 ` H. Peter Anvin
2013-06-29 19:29 ` Yinghai Lu
2013-06-29 19:29 ` Yinghai Lu
2013-06-29 19:29 ` Yinghai Lu
2013-06-29 19:55 ` Russell King - ARM Linux
2013-06-29 19:55 ` Russell King - ARM Linux
2013-06-29 19:55 ` Russell King - ARM Linux
2013-06-29 19:55 ` Russell King - ARM Linux
2013-06-29 20:08 ` Yinghai Lu
2013-06-29 20:08 ` Yinghai Lu
2013-06-29 20:08 ` Yinghai Lu
2013-07-01 14:10 ` Santosh Shilimkar
2013-07-01 14:10 ` Santosh Shilimkar
2013-07-01 14:10 ` Santosh Shilimkar
2013-07-01 14:10 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar
2013-07-25 22:33 ` Santosh Shilimkar
2013-07-25 22:36 ` Tejun Heo
2013-07-25 22:36 ` Tejun Heo
2013-07-25 22:36 ` Tejun Heo
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-25 23:15 ` Santosh Shilimkar
2013-07-26 3:08 ` Tejun Heo
2013-07-26 3:08 ` Tejun Heo
2013-07-26 3:08 ` Tejun Heo
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-02 21:06 ` Santosh Shilimkar
2013-08-05 15:01 ` Tejun Heo
2013-08-05 15:01 ` Tejun Heo
2013-08-05 15:01 ` Tejun Heo
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:29 ` Santosh Shilimkar
2013-08-05 15:38 ` Tejun Heo
2013-08-05 15:38 ` Tejun Heo
2013-08-05 15:38 ` Tejun Heo
2013-08-05 15:47 ` Santosh Shilimkar
2013-08-05 15:47 ` Santosh Shilimkar
2013-08-05 15:47 ` Santosh Shilimkar
2013-08-05 15:47 ` Santosh Shilimkar
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=20130629175743.GA382@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=davem@davemloft.net \
--cc=hpa@zytor.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=mingo@redhat.com \
--cc=nicolas.pitre@linaro.org \
--cc=paulus@samba.org \
--cc=sam@ravnborg.org \
--cc=santosh.shilimkar@ti.com \
--cc=sparclinux@vger.kernel.org \
--cc=will.deacon@arm.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.