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

[Hiroyuki KAMEZAWA <kamezawa.hiroyu@jp.fujitsu.com>]

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@jp.fujitsu.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>