Stephen C. Tweedie wrote:
> > I don't see why it's necessary though. The allocator should simply use
> > absolute address values for pairing instead of zone-relative
> > addresses.. is there anything more to it than that?
>
> Yes --- you need 8k allocations to be 8k-aligned physically, and 64k
> allocations to be 64k-aligned, etc. Just to think of one example, Intel
> MTRR absolutely requires that the address of a memory range is a
> multiple of the size of the range, and you need aligned zones to create
> such regions.
That's what I said. E.g., you have a zone starting at 4k that's 32k
long. You initialise the allocator by calling free_page on each page.
The buddy structure ends up looking like this:
4k @ 4k
16k @ 8k
4k @ 24k
In other words, you get aligned allocations without having to align the
zones. As far as I can see, it's a simple matter of making the "get
my opposite buddy page" logic use absolute address values instead of
zone-relative ones.
> This needn't be a problem --- you can easily create a zone aligned at a
> large (eg. 16MB) granularity, without filling it with free pages. As an
> example, the low-memory zone doesn't populate the free page list with
> pages in the 640k-1M hole. Just because your physical page region isn't
> aligned nicely doesn't mean you cannot align the zone itself.
I guess that's what I said too, but I don't see why aligning the zone is
needed. May as well leave zones representing actual memory ranges,
rather than some artificially aligned ranges for no obvious reason.
Less work for people writing ports, less to go invisibly wrong...
enjoy,
-- Jamie
-
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/
This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:15 EST