2006/7/6, Mel Gorman <[email protected]>:
I think my patch does the job of moving ARCH_PFN_OFFSET out of the hot
path in a less risky fashion. However, if you are sure that callers to
free_area_init() and ARCH_PFN_OFFSET are ok after your patch, I'd be happy
to go with it. If you're not sure, I reckon my patch would be the way to
go.
Ok I try to explain better what I have in mind. Your patch changes the
behaviour of free_area_init_node() in the sense that it doesn't work
as expected if its fourth parameter is different from ARCH_PFN_OFFSET,
it even becomes boggus IMHO. And I think it's valid to use it when
FLATMEM model is selected.
I don't know if there is a platform which uses FLATMEM model and do
not setup ARCH_PFN_OFFSET when its memory do not start at 0. But I
don't think we should assume that if FLATMEM model is selected then
all uses of free_area_init_node() imply ARCH_PFN_OFFSET whatever the
value of the fourth parameter. I would say it's a risky implementation
of free_area_init_node() and prone boggus uses of this function.
One example comes in mind, though I don't know if it's possible. Let's
say a platform can't determine where exactly its memory start. It has
to determine this start at boot time, the BIOS may pass it for
example. So in that case you can't use ARCH_PFN_OFFSET and you have to
use free_area_init_node() with a variable as fourth parameter.
--
Franck
-
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]
