Re: [RFC] buddy allocator without bitmap(2) [0/3]

[Dave Hansen]

On Tue, 2004-08-31 at 03:36, Hiroyuki KAMEZAWA wrote:
> Disadvantage:
>   - using one more PG_xxx flag.
>   - If mem_map is not aligned, reserve one page as a victim for buddy allocater.
> 
> How about this approach ?

Granted, we have some free wiggle room in page->flags right now, but
using another bit effectively shifts the entire benefit of your patch. 
Instead of getting rid of the buddy bitmaps, you simply consume a
page->flag instead.  While you don't have to allocate anything (because
of the page->flags use), the number of bits consumed in the operation is
still the same as before.  And the patch is getting more complex by the
minute.

Something ate your patch:

   * Global page accounting.  One instance per CPU.  Only unsigned longs are
@@ -290,6 +297,9 @@ extern unsigned long __read_page_state(u
  #define SetPageCompound(page) set_bit(PG_compound, &(page)->flags)
  #define ClearPageCompound(page)       clear_bit(PG_compound, &(page)->flags)

+#define PageBuddyend(page)      test_bit(PG_buddyend, &(page)->flags)
+#define SetPageBuddyend(page)   set_bit(PG_buddyend, &(page)->flags)
+
  #ifdef CONFIG_SWAP
  #define PageSwapCache(page)   test_bit(PG_swapcache, &(page)->flags)
  #define SetPageSwapCache(page)        set_bit(PG_swapcache, &(page)->flags)


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