Messages in this thread | | | Date | Wed, 10 Mar 2010 14:05:42 -0800 | From | Yinghai Lu <> | Subject | Re: [PATCH 5/6] early_res: seperate common memmap func from e820.c to fw_memmap.c |
| |
On 03/10/2010 01:50 PM, Russell King wrote: > On Wed, Mar 10, 2010 at 01:24:26PM -0800, Yinghai Lu wrote: >> +/* How much should we pad RAM ending depending on where it is? */ >> +static unsigned long __init ram_alignment(resource_size_t pos) >> +{ >> + unsigned long mb = pos >> 20; >> + >> + /* To 64kB in the first megabyte */ >> + if (!mb) >> + return 64*1024; >> + >> + /* To 1MB in the first 16MB */ >> + if (mb < 16) >> + return 1024*1024; >> + >> + /* To 64MB for anything above that */ >> + return 64*1024*1024; >> +} > > This doesn't make sense for generic code. > > 1. All architectures do not have RAM starting at physical address 0. > 2. What about architectures which have relatively little memory (maybe > 16MB total) split into four chunks of 4MB spaced at 512MB ?
> > Other comments: > > 1. It doesn't support mem=size@base, which is used extensively on ARM.
current x86, need to use exactmap... so could add sth in arch/arm/setup.c to set it.
> 2. How does memory get allocated for creating things like page tables? find_fw_memmap_area rerserve_early
> > Currently, bootmem supports ARM very well with support for flatmem, > sparsemem and discontigmem models (the latter being deprecated). Can > this code support all three models? should be ok. > > Where are patches 1 to 4?
my bad, it still have 1/4, 2/4, 3/4, 4/4
> > Lastly, why exactly is bootmem being eliminated? Bootmem offers more > flexible functionality than this e820 code appears at first read-through > seems to. less layer before slab...
fw_memmap.c could be simplified by keeping more stuff in arch/x86/kernel/e820.c will have one fw_mem_internal.h and only be included by fw_memmap.c and arch fw_memmap.c.
YH
| |