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

From: Dave Hansen
Date: Tue Aug 31 2004 - 18:31:27 EST


On Tue, 2004-08-31 at 15:55, Hiroyuki KAMEZAWA wrote:
> 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 ?

If the end of the zone isn't aligned, you simply waste memory until it becomes aligned, right?

> 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.

If you adjust the zone_spanned pages properly, this shouldn't happen.

-- Dave

-
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/