Ping, :-)
On 03/06/2013 08:21 AM, Simon Jeons wrote:
On 03/05/2013 11:08 PM, Jiang Liu wrote:
On 03/05/2013 08:19 PM, Simon Jeons wrote:
On 03/05/2013 12:37 AM, Jiang Liu wrote:
On 03/04/2013 07:57 AM, Simon Jeons wrote:
Hi Jiang,
On 03/03/2013 11:43 PM, Jiang Liu wrote:
Hi Simon,
Bootmem allocator is used to managed DMA and Normal memory
only, and it does not manage highmem pages because kernel
can't directly access highmem pages.
Why you say so? Could you point out where you figure out bootmem
allocator doesn't handle highmem pages? In my understanding, it
doesn't distinguish low memory or high memory.
Hi Simon,
Hi Jiang,
The comments of max_pfn_mapped is "highest direct mapped pfn over
4GB", so if both bootmem allocator and memblock just manage direct
mapping pages?
BTW, could you show me where you can figure out traditional bootmem
allocator manages directly mapping pages?
Hi Simon,
Bootmem allocator only manages directly mapped pages, but
memblock could manage all pages.
For traditional bootmem allocator, you could trace back callers of
init_bootmem_node() and init_bootmem()
to get the idea.
Hi Jiang,
I track the callset of init_bootmem() against openrisc
architecture(arch/openrisc/kernel/setup.c), it seems that it manages
all the memory instead of low memory you mentioned. BTW, I didn't read
x86_64 direct mapping codes before, if has enough big memory, what's
the range of direct mapping?
Regards!
Gerry
According to my understanding, bootmem allocator does only
manages lowmem pages.
For traditional bootmem allocator in mm/bootmem.c, it could only
manages directly mapped lowmem pages.
For new bootmem allocator in mm/nobootmem.c, it depends on memblock
to do the real work. Let's take
x86 as an example:
1) following code set memblock.current_limit to max_low_pfn.
arch/x86/kernel/setup.c: memblock.current_limit = get_max_mapped();
2) the core of bootmem allocator in nobootmem.c is function
__alloc_memory_core_early(),
which has following code to avoid allocate highmem pages:
static void * __init __alloc_memory_core_early(int nid, u64 size,
u64 align,
u64 goal, u64 limit)
{
void *ptr;
u64 addr;
if (limit > memblock.current_limit)
limit = memblock.current_limit;
addr = memblock_find_in_range_node(goal, limit, size,
align, nid);
if (!addr)
return NULL;
}
I guess it's the same for other architectures. On the other hand,
some other architectures
may allocate highmem pages during boot by directly using memblock
interfaces. For example,
ppc use memblock interfaces to allocate highmem pages for giagant
hugetlb pages.
I'm working a patch set to fix those cases.
Regards!
Gerry
Regards!
Gerry
On 02/28/2013 02:13 PM, Simon Jeons wrote:
Hi Jiang,
https://patchwork.kernel.org/patch/1781291/
You said that the bootmem allocator doesn't touch *highmem
pages*, so highmem zones' managed_pages is set to the accurate
value "spanned_pages - absent_pages" in function
free_area_init_core() and won't be updated anymore. Why it
doesn't touch *highmem pages*? Could you point out where you
figure out this?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>