> Below are three patches. The first to setup.c fixes a problem my BP6 was
> triggering in the new E820/bootmem code -- one of the memory regions was a
> paltry 1KB in size, and it wasn't being skipped properly.
(cool)
> The second to bootmem.c fixes the problem with all memory being marked as
> DMA.
(embarrasing! i managed to put two serious bugs into a twoliner, hm.)
> The third to page_alloc.c is not an essential fix, but rather a forward
> port of a patch in 2.2.13 that splits GFP_DMA pages into a separate list
> from non-DMA pages. This helps keep the system's DMA pool at a higher
> steady state since the last of the DMAable pages will only be consumed by
> atomic allocations. Personally, I think it makes the high memory stuff
> look a bit more tidy =)
>
> This patch is against 2.3.23pre4 plus Ingo's highmem-2.3.23-D3 patch.
nice cleanups, and this now looks more and more like a zoned allocator.
there is one detail that i think still needs fixing: all three zones now
have basically the same bitmap size, which can take up a considerable
amount of memory:
DMA: xxx.........................................
normal mem: ...xxxxxxxxxxxxxxxxxxxxxx...................
highmem: .........................xxxxxxxxxxxxxxxxxxx
the more zones we have, the more vastage - currently bitmaps are three
times as big as they need to be.
We do not need the dynamic overhead of an area->offset though, we can just
tweak frea_area[][].map's address in a way that offsets it exactly in such
a way that makes page indices universally correct in the current sense.
And not memset() all of free_area[][].map when initializing :)
-- mingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/