From: David Miller on
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
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
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
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
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