early_res: seperate common memmap func from e820.c to fw_memmap.c
in [Kernel]
|
Prev: early_res: seperate common memmap func from e820.c to fw_memmap.c
Next: [PATCH] USB-SERIAL cp210x: Remove double usb_control_msg from cp210x_set_config
From: David Miller on 10 Mar 2010 17:00 From: Russell King <rmk+lkml(a)arm.linux.org.uk> Date: Wed, 10 Mar 2010 21:50:18 +0000 > Where are patches 1 to 4? They were x86 specific, from the perspective of your architecture you only need to look at the non-x86 parts of patch #5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 10 Mar 2010 17:10 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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paul Mackerras on 10 Mar 2010 18:50 On Wed, Mar 10, 2010 at 01:24:26PM -0800, Yinghai Lu wrote: > move it to kernel/fw_memmap.c from arch/x86/kernel/e820.c > > Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> > > --- > arch/x86/include/asm/e820.h | 130 ----- > arch/x86/kernel/e820.c | 1142 -------------------------------------------- > include/linux/bootmem.h | 2 > include/linux/fw_memmap.h | 114 ++++ > kernel/Makefile | 2 > kernel/fw_memmap.c | 1134 +++++++++++++++++++++++++++++++++++++++++++ Yuck. So you think we should use > 1100 lines of fw_memmap.c code instead of the 541 lines of lib/lmb.c? Why exactly would that be better? Paul. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 10 Mar 2010 19:10 On 03/10/2010 03:46 PM, Paul Mackerras wrote: > On Wed, Mar 10, 2010 at 01:24:26PM -0800, Yinghai Lu wrote: > >> move it to kernel/fw_memmap.c from arch/x86/kernel/e820.c >> >> Signed-off-by: Yinghai Lu <yinghai(a)kernel.org> >> >> --- >> arch/x86/include/asm/e820.h | 130 ----- >> arch/x86/kernel/e820.c | 1142 -------------------------------------------- >> include/linux/bootmem.h | 2 >> include/linux/fw_memmap.h | 114 ++++ >> kernel/Makefile | 2 >> kernel/fw_memmap.c | 1134 +++++++++++++++++++++++++++++++++++++++++++ > > Yuck. So you think we should use > 1100 lines of fw_memmap.c code > instead of the 541 lines of lib/lmb.c? Why exactly would that be > better? > even worse you should count early_res + fw_memmap YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on 22 Mar 2010 00:00
On 03/21/2010 07:37 PM, Benjamin Herrenschmidt wrote: > On Sun, 2010-03-21 at 00:13 -0700, Yinghai Lu wrote: >> move it to kernel/fw_memmap.c from arch/x86/kernel/e820.c >> >> -v2: add fw_memmap wrapper to some func... >> move some functions back to e820.c > > NAK at this point, kernel/early_res.c and kernel/fw_memmap.c is protected with HAVE_EARLY_RES obj-$(CONFIG_HAVE_EARLY_RES) += early_res.o fw_memmap.o so it will not increase size that doesn't support early_res/bootmem yet. > > This is even worse than before. You are now moving that entire pile of > x86 gunk into "generic" code, but even keep it names e820 there ! not all of the e820 code. arch/x86/kernel/e820.c are still there. linux-2.6> wc -l arch/x86/kernel/e820.c 690 arch/x86/kernel/e820.c linux-2.6> wc -l kernel/fw_memmap.c 625 kernel/fw_memmap.c and interface header file yhlu(a)linux-siqj:~/xx/xx/kernel/tip/linux-2.6> cat include/linux/fw_memmap.h #ifndef _LINUX_FW_MEMMAP_H #define _LINUX_FW_MEMMAP_H #define E820MAX 128 /* number of entries in E820MAP */ #define FW_MEMMAP_RAM 1 #define FW_MEMMAP_RESERVED 2 #define E820_RAM FW_MEMMAP_RAM #define E820_RESERVED FW_MEMMAP_RESERVED #define E820_ACPI 3 #define E820_NVS 4 #define E820_UNUSABLE 5 #ifndef __ASSEMBLY__ #include <linux/types.h> struct e820entry { __u64 addr; /* start of memory segment */ __u64 size; /* size of memory segment */ __u32 type; /* type of memory segment */ } __attribute__((packed)); #ifdef __KERNEL__ void fw_memmap_add_region(u64 start, u64 size, int type); void fw_memmap_print_map(char *who); int sanitize_fw_memmap(void); void finish_fw_memmap_parsing(void); #include <linux/early_res.h> unsigned long fw_memmap_end_of_ram_pfn(void); void fw_memmap_register_active_regions(int nid, unsigned long start_pfn, unsigned long end_pfn); u64 fw_memmap_hole_size(u64 start, u64 end); #endif /* __KERNEL__ */ #endif /* __ASSEMBLY__ */ #endif /* _LINUX_FW_MEMMAP_H */ and new arch that support early_res/bootmem, will normally only need to call those six functions like +void __init setup_memory_map(void) +{ + int i; + unsigned long phys_base; + /* Find available physical memory... + * + * Read it twice in order to work around a bug in openfirmware. + * The call to grab this table itself can cause openfirmware to + * allocate memory, which in turn can take away some space from + * the list of available memory. Reading it twice makes sure + * we really do get the final value. + */ + read_obp_translations(); + read_obp_memory("reg", &pall[0], &pall_ents); + read_obp_memory("available", &pavail[0], &pavail_ents); + read_obp_memory("available", &pavail[0], &pavail_ents); + + phys_base = 0xffffffffffffffffUL; + for (i = 0; i < pavail_ents; i++) { + phys_base = min(phys_base, pavail[i].phys_addr); + fw_memmap_add_region(pavail[i].phys_addr, pavail[i].reg_size, + FW_MEMMAP_RAM); + } + + sanitize_fw_memmap(); + + fw_memmap_print_map("obp memmap:"); > > What happened to the discussion we had earlier, which iirc concluded > that a better approach would be to adapt x86 to use LMB ? e820/early_res is more complicated than lmb. to make x86, we still need to keep e820 related code. and early_res already can be used to replace bootmem code. maybe we should find other user other than previous lmb users at first. attached is the one for sparc64/lmb converting...- i have no chance to debug it. qemu seems doesn't support sparc64 well yet. Yinghai |