From: neidhard.kim@lge.com (Kim, Jong-Sung)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Thu, 28 Jun 2012 15:08:39 +0900 [thread overview]
Message-ID: <00e901cd54f4$76773650$6365a2f0$@lge.com> (raw)
In-Reply-To: <20120627191801.GD25319@n2100.arm.linux.org.uk>
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
> Sent: Thursday, June 28, 2012 4:18 AM
> On Fri, Jun 08, 2012 at 10:58:50PM +0900, Kim, Jong-Sung wrote:
> >
> > May I suggest another simple approach? The first continuous couples of
> > sections are always safely section-mapped inside alloc_init_section
> funtion.
> > So, by limiting memblock_alloc to the end of the first continuous
> > couples of sections at the start of map_lowmem, map_lowmem can safely
> > memblock_alloc & memset even if we have one or more section-unaligned
> > memory regions. The limit can be extended back to arm_lowmem_limit after
> the map_lowmem is done.
>
> No. What if the first block of memory is not large enough to handle all
the
> allocations?
>
Thank you for your comment, Russell. I sent a modified patch not to limit to
the first memory memblock_region as a reply to Dave's message.
> I think the real problem is folk trying to reserve small amounts. I have
> said all reservations must be aligned to 1MB.
>
Ok, now I know your thought about arm_memblock_steal(). Then, how about
adding a simple aligning to prevent the possible problem just like me:
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..d0daf0d 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -324,6 +324,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size,
phys
BUG_ON(!arm_memblock_steal_permitted);
+ size = ALIGN(size, SECTION_SIZE);
+
phys = memblock_alloc(size, align);
memblock_free(phys, size);
memblock_remove(phys, size);
or, leaving a few comments about the restriction kindly..?
WARNING: multiple messages have this Message-ID (diff)
From: "Kim, Jong-Sung" <neidhard.kim@lge.com>
To: 'Russell King - ARM Linux' <linux@arm.linux.org.uk>
Cc: 'Minchan Kim' <minchan@kernel.org>,
'Nicolas Pitre' <nico@linaro.org>,
'Catalin Marinas' <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, 'Chanho Min' <chanho.min@lge.com>,
linux-mm@kvack.org
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Thu, 28 Jun 2012 15:08:39 +0900 [thread overview]
Message-ID: <00e901cd54f4$76773650$6365a2f0$@lge.com> (raw)
In-Reply-To: <20120627191801.GD25319@n2100.arm.linux.org.uk>
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Thursday, June 28, 2012 4:18 AM
> On Fri, Jun 08, 2012 at 10:58:50PM +0900, Kim, Jong-Sung wrote:
> >
> > May I suggest another simple approach? The first continuous couples of
> > sections are always safely section-mapped inside alloc_init_section
> funtion.
> > So, by limiting memblock_alloc to the end of the first continuous
> > couples of sections at the start of map_lowmem, map_lowmem can safely
> > memblock_alloc & memset even if we have one or more section-unaligned
> > memory regions. The limit can be extended back to arm_lowmem_limit after
> the map_lowmem is done.
>
> No. What if the first block of memory is not large enough to handle all
the
> allocations?
>
Thank you for your comment, Russell. I sent a modified patch not to limit to
the first memory memblock_region as a reply to Dave's message.
> I think the real problem is folk trying to reserve small amounts. I have
> said all reservations must be aligned to 1MB.
>
Ok, now I know your thought about arm_memblock_steal(). Then, how about
adding a simple aligning to prevent the possible problem just like me:
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..d0daf0d 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -324,6 +324,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size,
phys
BUG_ON(!arm_memblock_steal_permitted);
+ size = ALIGN(size, SECTION_SIZE);
+
phys = memblock_alloc(size, align);
memblock_free(phys, size);
memblock_remove(phys, size);
or, leaving a few comments about the restriction kindly..?
--
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: "Kim, Jong-Sung" <neidhard.kim@lge.com>
To: "'Russell King - ARM Linux'" <linux@arm.linux.org.uk>
Cc: "'Minchan Kim'" <minchan@kernel.org>,
"'Nicolas Pitre'" <nico@linaro.org>,
"'Catalin Marinas'" <catalin.marinas@arm.com>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>,
"'Chanho Min'" <chanho.min@lge.com>, <linux-mm@kvack.org>
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc
Date: Thu, 28 Jun 2012 15:08:39 +0900 [thread overview]
Message-ID: <00e901cd54f4$76773650$6365a2f0$@lge.com> (raw)
In-Reply-To: <20120627191801.GD25319@n2100.arm.linux.org.uk>
> From: Russell King - ARM Linux [mailto:linux@arm.linux.org.uk]
> Sent: Thursday, June 28, 2012 4:18 AM
> On Fri, Jun 08, 2012 at 10:58:50PM +0900, Kim, Jong-Sung wrote:
> >
> > May I suggest another simple approach? The first continuous couples of
> > sections are always safely section-mapped inside alloc_init_section
> funtion.
> > So, by limiting memblock_alloc to the end of the first continuous
> > couples of sections at the start of map_lowmem, map_lowmem can safely
> > memblock_alloc & memset even if we have one or more section-unaligned
> > memory regions. The limit can be extended back to arm_lowmem_limit after
> the map_lowmem is done.
>
> No. What if the first block of memory is not large enough to handle all
the
> allocations?
>
Thank you for your comment, Russell. I sent a modified patch not to limit to
the first memory memblock_region as a reply to Dave's message.
> I think the real problem is folk trying to reserve small amounts. I have
> said all reservations must be aligned to 1MB.
>
Ok, now I know your thought about arm_memblock_steal(). Then, how about
adding a simple aligning to prevent the possible problem just like me:
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index f54d592..d0daf0d 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -324,6 +324,8 @@ phys_addr_t __init arm_memblock_steal(phys_addr_t size,
phys
BUG_ON(!arm_memblock_steal_permitted);
+ size = ALIGN(size, SECTION_SIZE);
+
phys = memblock_alloc(size, align);
memblock_free(phys, size);
memblock_remove(phys, size);
or, leaving a few comments about the restriction kindly..?
next prev parent reply other threads:[~2012-06-28 6:08 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-05 7:11 [PATCH] [RESEND] arm: limit memblock base address for early_pte_alloc Minchan Kim
2012-06-05 7:11 ` Minchan Kim
2012-06-05 7:11 ` Minchan Kim
2012-06-08 13:58 ` Kim, Jong-Sung
2012-06-08 13:58 ` Kim, Jong-Sung
2012-06-08 13:58 ` Kim, Jong-Sung
2012-06-27 16:02 ` Dave Martin
2012-06-27 16:02 ` Dave Martin
2012-06-27 16:02 ` Dave Martin
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 5:43 ` Kim, Jong-Sung
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:25 ` Nicolas Pitre
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-28 6:54 ` Kim, Jong-Sung
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-27 19:18 ` Russell King - ARM Linux
2012-06-28 6:08 ` Kim, Jong-Sung [this message]
2012-06-28 6:08 ` Kim, Jong-Sung
2012-06-28 6:08 ` Kim, Jong-Sung
2012-06-19 8:38 ` Minchan Kim
2012-06-19 8:38 ` Minchan Kim
2012-06-19 8:38 ` Minchan Kim
2012-06-27 16:12 ` Dave Martin
2012-06-27 16:12 ` Dave Martin
2012-06-27 16:12 ` Dave Martin
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:33 ` Nicolas Pitre
2012-06-28 4:46 ` Minchan Kim
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 9:08 ` Russell King - ARM Linux
2012-06-28 17:50 ` Nicolas Pitre
2012-06-28 17:50 ` Nicolas Pitre
2012-06-28 17:50 ` Nicolas Pitre
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='00e901cd54f4$76773650$6365a2f0$@lge.com' \
--to=neidhard.kim@lge.com \
--cc=linux-arm-kernel@lists.infradead.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: 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.