Re: 2.6.17-mm1

[Franck Bui-Huu]

2006/6/22, Mel Gorman <mel@xxxxxxxxx>:
> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
>
> > Mel Gorman wrote:
> >> On Thu, 22 Jun 2006, Franck Bui-Huu wrote:
> >>>
> >>> Should ARCH_PFN_OFFSET macro be used instead in order to make pfn/page
> >>> convertions work when node 0 start offset do not start at 0 ?
> >>>
> >>
> >> What happens if you have ARCH_PFN_OFFSET as
> >>
> >> #define ARCH_PFN_OFFSET (0UL)
> >>
> >> ?
> >
> > It's the default value (see memory_model.h). It means that pfn start
> > for node 0 is 0, therefore your physical memory address starts at 0.
> >
>
> I know, but what I'm getting at is that ARCH_PFN_OFFSET may be unnecessary
> with flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch applied.

yes it seems so. But ARCH_PFN_OFFSET has been used before your patch
has been sent. So your patch seems to be incomplete...

> ARCH_PFN_OFFSET is used as
>
> #define page_to_pfn(page)       ((unsigned long)((page) - mem_map) + \
>                                   ARCH_PFN_OFFSET)
>
> because it knew that the map may not start at PFN 0. With
> flatmem-relax-requirement-for-memory-to-start-at-pfn-0.patch, the map will
> start at PFN 0 even if physical memory does not start until later.

well your approach's trick is on the mem_map address whereas
ARCH_PFN_OFFSET's one is on the computation of the index. Your
solution may result in smaller kernel (when ARCH_PFN_OFFSET != 0)
because in your case page/pfn conversion is simpler.

Maybe in your patch instead of doing:

       map -= pgdat->node_start_pfn;

you could do:

       map -= ARCH_OFFSET_PFN;

--
              Franck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/