Re: [PATCH 1/1] Only use ARCH_PFN_OFFSET once during boot

["Franck Bui-Huu" <vagabon.xyz@gmail.com>]

2006/7/6, Mel Gorman <mel@csn.ul.ie>:
> 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 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/