Messages in this thread | | | Date | Wed, 16 Nov 2005 02:07:17 +0000 (GMT) | From | Mel Gorman <> | Subject | Re: [PATCH 2/5] Light Fragmentation Avoidance V20: 002_usemap |
| |
On Wed, 16 Nov 2005, Andi Kleen wrote:
> On Wednesday 16 November 2005 02:43, Mel Gorman wrote: > > > 1. I was using a page flag, valuable commodity, thought I would get kicked > > for it. Usemap uses 1 bit per 2^(MAX_ORDER-1) pages. Page flags uses > > 2^(MAX_ORDER-1) bits at worse case. > > Why does it need multiple bits? A page can only be in one order at a > time, can't it? >
Yes, but 1024 pages in one block is one bit per page. Usemap uses 1 page for all 1024.
> > 2. Fragmentation avoidance tended to break down, very fast. > > Why? The algorithm should the same, no? >
That's what I thought when I wrote it first but it broke down fast according to bench-stresshighalloc. I'll need to re-examine the patches and see where I went wrong.
> > 3. When changing a block of pages from one type to another, there was no > > fast way to make sure all pages currently allocation would end up on > > the correct free list > > If you can change the bitmap you can change as well mem_map >
That's iterating through, potentially, 1024 pages which I considered too expensive. In terms of code complexity, the page-flags patch adds 237 which is not much of a saving in comparison to 275 that the usemap approach uses.
Again, I can revisit the page-flag approach if I thought that something like this would get merged and people would not choke on another page flag being consumed.
-- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - 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/
| |