set_phys_avail() futures question

set_phys_avail() futures question

[Jon Loeliger]

Ben (primarily),

I'd like to get your opinion on what the future of
arch/ppc/mm/init.c/set_phys_avail() looks like.
Currently, its job is to traverse the mem_pieces data
and remove a whole series of #ifdef'ed regions of
memory based on configuration options.  These regions
are the initrd, the RTAS data, and the AGP special page.

Do you see these regions as being explicitly listed in 
the proposed  "reserved memory blocks" area of the Flat
Dev Tree header structure?

If so, then they would follow the same conceptual flow
as the ppc64 reservations in the LMB.  They would then
be SetPagReserved() and removed from the do_init_bootmem()
regions of memory as well.

Thanks,
jdl

Re: set_phys_avail() futures question

[Benjamin Herrenschmidt]

On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
> Ben (primarily),
> 
> I'd like to get your opinion on what the future of
> arch/ppc/mm/init.c/set_phys_avail() looks like.
> Currently, its job is to traverse the mem_pieces data
> and remove a whole series of #ifdef'ed regions of
> memory based on configuration options.  These regions
> are the initrd, the RTAS data, and the AGP special page.
> 
> Do you see these regions as being explicitly listed in 
> the proposed  "reserved memory blocks" area of the Flat
> Dev Tree header structure?

Yes. initrd for sure, RTAS too, AGP special page well ... I have to
check if we still use that one at all... but it's not allocated in
prom_init so it may need it's own little bit here still.

> If so, then they would follow the same conceptual flow
> as the ppc64 reservations in the LMB.  They would then
> be SetPagReserved() and removed from the do_init_bootmem()
> regions of memory as well.

I'm not sure we actually need to explicitely call SetPageReserved(), do
we ? As long as they are not returned to the free pool ...  Oh well,
that can't hurt :)

Ben.

Re: set_phys_avail() futures question

[Kumar Gala]

On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:

> On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
>
>> Ben (primarily),
>>
>> I'd like to get your opinion on what the future of
>> arch/ppc/mm/init.c/set_phys_avail() looks like.
>> Currently, its job is to traverse the mem_pieces data
>> and remove a whole series of #ifdef'ed regions of
>> memory based on configuration options.  These regions
>> are the initrd, the RTAS data, and the AGP special page.
>>
>> Do you see these regions as being explicitly listed in
>> the proposed  "reserved memory blocks" area of the Flat
>> Dev Tree header structure?
>>
>
> Yes. initrd for sure, RTAS too, AGP special page well ... I have to
> check if we still use that one at all... but it's not allocated in
> prom_init so it may need it's own little bit here still.

What this implies to me is that what a flattened OF tree we will no  
longer need to call set_phys_avail().

- kumar

Re: set_phys_avail() futures question

[Benjamin Herrenschmidt]

On Thu, 2005-06-30 at 00:06 -0500, Kumar Gala wrote:
> On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:
> 
> > On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
> >
> >> Ben (primarily),
> >>
> >> I'd like to get your opinion on what the future of
> >> arch/ppc/mm/init.c/set_phys_avail() looks like.
> >> Currently, its job is to traverse the mem_pieces data
> >> and remove a whole series of #ifdef'ed regions of
> >> memory based on configuration options.  These regions
> >> are the initrd, the RTAS data, and the AGP special page.
> >>
> >> Do you see these regions as being explicitly listed in
> >> the proposed  "reserved memory blocks" area of the Flat
> >> Dev Tree header structure?
> >>
> >
> > Yes. initrd for sure, RTAS too, AGP special page well ... I have to
> > check if we still use that one at all... but it's not allocated in
> > prom_init so it may need it's own little bit here still.
> 
> What this implies to me is that what a flattened OF tree we will no  
> longer need to call set_phys_avail().

It will have to do some equivalent to transfer the reserve map to
mem_pieces tho ...

Ben.

Re: set_phys_avail() futures question

[Kumar Gala]

>>>> I'd like to get your opinion on what the future of
>>>> arch/ppc/mm/init.c/set_phys_avail() looks like.
>>>> Currently, its job is to traverse the mem_pieces data
>>>> and remove a whole series of #ifdef'ed regions of
>>>> memory based on configuration options.  These regions
>>>> are the initrd, the RTAS data, and the AGP special page.
>>>>
>>>> Do you see these regions as being explicitly listed in
>>>> the proposed  "reserved memory blocks" area of the Flat
>>>> Dev Tree header structure?
>>>>
>>>>
>>>
>>> Yes. initrd for sure, RTAS too, AGP special page well ... I have to
>>> check if we still use that one at all... but it's not allocated in
>>> prom_init so it may need it's own little bit here still.
>>>
>>
>> What this implies to me is that what a flattened OF tree we will no
>> longer need to call set_phys_avail().
>>
>
> It will have to do some equivalent to transfer the reserve map to
> mem_pieces tho ...

Agreed, but I think we expect that to happen in platform_init now.   
When we walk the flatten tree we will build up the phys_avail  
mem_pieces data structure.

- kumar