lkml.org 
[lkml]   [2006]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-06-22 19:28    [W:0.123 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site