lkml.org 
[lkml]   [2001]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectBuddy allocator - help! I thought I understood this
I could swear I understood this bit of __free_pages_ok()
Monday night, but my mind appears to have gone blank.

As I recall, the memory bitmaps indicate by the
status a bit op returns whether or not a page
is on the free list for that particular order
area.

So how does this work (lines from vanilla 2.4.9
attached). I'm interested particularly in line
114:

if (!__test_and_change_bit(index, area->map))

This examines the bitmap entry, in the
current order being examined bitmap.

As the page is being free'd, on the first pass,
won't the page ALWAYS register as unallocated?
This claims to test whether the buddy page
is still allocated. Wouldn't this test be:

if (!__test_and_change_bit(index^1, area->map))

The annoying thing is I'm SURE I read through
this and understood it fully Monday night.

Or is the bitmap trying to tell us whether the
BUDDY is used? This doesn't seem to be what
expand et al are doing.

Please help - my head hurts.

(NB, if this is a code bug rather than local brain
bug, this explains a lot)
--
Alex Bligh



99 if (page_idx & ~mask)
100 BUG();
101 index = page_idx >> (1 + order);
102
103 area = zone->free_area + order;
104
105 spin_lock_irqsave(&zone->lock, flags);
106
107 zone->free_pages -= mask;
108
109 while (mask + (1 << (MAX_ORDER-1))) {
110 struct page *buddy1, *buddy2;
111
112 if (area >= zone->free_area + MAX_ORDER)
113 BUG();
114 if (!__test_and_change_bit(index, area->map))
115 /*
116 * the buddy page is still allocated.
117 */
118 break;
119 /*
120 * Move the buddy up one level.
121 */


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

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:0.400 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site