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
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.
On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:
On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
quoted
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
On Thu, 2005-06-30 at 00:06 -0500, Kumar Gala wrote:
On Jun 29, 2005, at 6:56 PM, Benjamin Herrenschmidt wrote:
quoted
On Wed, 2005-06-29 at 16:14 -0500, Jon Loeliger wrote:
quoted
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.
quoted
quoted
quoted
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