Re: [Lhms-devel] Re: [RFC] buddy allocator without bitmap(2) [1/3]

From: Hiroyuki KAMEZAWA
Date: Tue Aug 31 2004 - 17:54:52 EST


Dave Hansen wrote:

> On Tue, 2004-08-31 at 03:41, Hiroyuki KAMEZAWA wrote:
>
>>+static void __init calculate_aligned_end(struct zone *zone,
>>+ unsigned long start_pfn,
>>+ int nr_pages)
>
> ...
>
>>+ end_address = (zone->zone_start_pfn + end_idx) << PAGE_SHIFT;
>>+#ifndef CONFIG_DISCONTIGMEM
>>+ reserve_bootmem(end_address,PAGE_SIZE);
>>+#else
>>+ reserve_bootmem_node(zone->zone_pgdat,end_address,PAGE_SIZE);
>>+#endif
>>+ }
>>+ return;
>>+}
>
>
> What if someone has already reserved that address? You might not be
> able to grow the zone, right?
>
1) If someone has already reserved that address, it (the page) will not join to
buddy allocator and it's no problem.

2) No, I can grow the zone.
A reserved page is the last page of "not aligned contiguous mem_map", not zone.

I answer your question ?

I know this patch contains some BUG, if a page is allocateed when calculate_alinged_end()
is called, and is freed after calling this, it is never reserved and join to buddy system.

>
>>+ /* Because memmap_init_zone() is called in suitable way
>>+ * even if zone has memory holes,
>>+ * calling calculate_aligned_end(zone) here is reasonable
>>+ */
>>+ calculate_aligned_end(zonep, saved_start_pfn, size);
>
>
> Could you please elaborate on "suitable way". That comment really
> doesn't say anything.
I'll rewrite this.
/*
* calculate_aligned_end() has to be called by each contiguous mem_map.
*/




--
--the clue is these footmarks leading to the door.--
KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/