Andy Whitcroft wrote:
I agree that there is no need for these checks to leak out of
page_is_buddy(). If its not there or in another zone, its not my buddy.
The allocator loop is nasty enough as it is.
OK, glad you agree.
I think we need to do a couple of things:
1) check the alignment of the zones matches the implied alignment
constraints and correct it as we go.
Yes. And preferably have checks in the generic page allocator setup
code, so we can do something sane if the arch code gets it wrong.
2) optionally allow an architecture to say its not aligning and doesn't
want to have to align its zone -- providing a config option to add the
zone index checks
I think the later is valuable for these test builds and potentially for
the embedded side where megabytes mean something.
Yes. Depends whether we fold it under the HOLES_IN_ZONE config. I guess
HOLES_IN_ZONE is potentially quite a bit more expensive than the plain
zone check, so having 2 config options may not be unreasonable.
Also, if the architecture doesn't align the ends of zones, *and* they are
not adjacent to another zone, they need either CONFIG_HOLES_IN_ZONE or
they need to provide dummy 'struct page's that never have PageBuddy set.
I'm testing a patch for this at the moment and will drop it out when I'm
done.
Great!
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
