Messages in this thread | | | Date | Thu, 22 Jun 2006 19:25:57 +0200 | From | "Franck Bui-Huu" <> | Subject | Re: 2.6.17-mm1 |
| |
2006/6/22, Mel Gorman <mel@csn.ul.ie>: > 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |