[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1206280223250.31003@xanadu.home>
Date: Thu, 28 Jun 2012 02:25:59 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: "Kim, Jong-Sung" <neidhard.kim@....com>
cc: 'Dave Martin' <dave.martin@...aro.org>,
'Minchan Kim' <minchan@...nel.org>,
'Russell King' <linux@....linux.org.uk>,
'Catalin Marinas' <catalin.marinas@....com>,
'Chanho Min' <chanho.min@....com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-arm-kernel@...ts.infradead.org
Subject: RE: [PATCH] [RESEND] arm: limit memblock base address for
early_pte_alloc
On Thu, 28 Jun 2012, Kim, Jong-Sung wrote:
> > From: Dave Martin [mailto:dave.martin@...aro.org]
> > Sent: Thursday, June 28, 2012 1:02 AM
> >
> > For me, it appears that this block just contains the initial region passed
> > in ATAG_MEM or on the command line, with some reservations for
> > swapper_pg_dir, the kernel text/data, device tree and initramfs.
> >
> > So far as I can tell, the only memory guaranteed to be mapped here is the
> > kernel image: there may be no guarantee that there is any unused space in
> > this region which could be used to allocate extra page tables.
> > The rest appears during the execution of map_lowmem().
> >
> > Cheers
> > ---Dave
>
> Thank you for your comment, Dave! It was not that sophisticated choice, but
> I thought that normal embedded system trying to reduce the BOM would have a
> big-enough first memblock memory region. However you're right. There can be
> exceptional systems. Then, how do you think about following manner:
[...]
This still has some possibilities for failure.
Please have a look at the two patches I've posted to fix this in a
better way.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists