I'm running 2.6.11 on a Freescale 8555 with 1GB of DDR memory. =20
Looking in arch/ppc/mm/fsl_booke_mmu.c, I see that at most 3 TLB
entries will be used to map memory. Since the max tlb size on
Freescale Book E is 256 MB, this caps mapped in memory at 768 MB.
I've modified fsl_booke_mmu.c to use a 4th TLB, thus mapping the full
1 GB of memory. However, I'm new to linux memory management, so I'd
appreciate any comments as to whether there are tradeoffs or dangers
here that I am missing.
Thanks,
Kylo
On Jun 9, 2005, at 5:09 PM, Kylo Ginsberg wrote:
I'm running 2.6.11 on a Freescale 8555 with 1GB of DDR memory.
Looking in arch/ppc/mm/fsl_booke_mmu.c, I see that at most 3 TLB
entries will be used to map memory. Since the max tlb size on
Freescale Book E is 256 MB, this caps mapped in memory at 768 MB.
I've modified fsl_booke_mmu.c to use a 4th TLB, thus mapping the full
1 GB of memory. However, I'm new to linux memory management, so I'd
appreciate any comments as to whether there are tradeoffs or dangers
here that I am missing.
There is a danger here in that you have left no virtual address space
for the kernel. Since KERNEL_BASE is normally 0xc000_0000 + 1G ends up
a the end of memory. There for any devices that need virtual memory
space would not have any to map out of. I'm kinda amazed this works at
all. I'd be interested in seeing what a boot log looks like for this
config.
The way to handle this is by enabling HIGHMEM support in the kernel or
dropping the KERNEL_START in the config. I'm haven't ever tried to
drop KERNEL_START so your milage may very on what if anything that will
break.
- kumar
On 6/9/05, Kumar Gala [off-list ref] wrote:
=20
On Jun 9, 2005, at 5:09 PM, Kylo Ginsberg wrote:
quoted
I've modified fsl_booke_mmu.c to use a 4th TLB, thus mapping the full
1 GB of memory. However, I'm new to linux memory management, so I'd
appreciate any comments as to whether there are tradeoffs or dangers
here that I am missing.
=20
There is a danger here in that you have left no virtual address space
for the kernel. Since KERNEL_BASE is normally 0xc000_0000 + 1G ends up
a the end of memory. There for any devices that need virtual memory
space would not have any to map out of. I'm kinda amazed this works at
all. I'd be interested in seeing what a boot log looks like for this
config.
Sorry, should have mentioned this in the first post. I dropped
KERNEL_BASE to 0xa0000000 and upped LOWMEM_SIZE to 0x40000000. So the
Advanced Setup portion of my .config reads:
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=3Dy
CONFIG_HIGHMEM_START=3D0xfe000000
CONFIG_LOWMEM_SIZE_BOOL=3Dy
CONFIG_LOWMEM_SIZE=3D0x40000000
CONFIG_KERNEL_START_BOOL=3Dy
CONFIG_KERNEL_START=3D0xa0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=3D0x80000000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=3D0x00800000
and under Platform Options:
# CONFIG_HIGHMEM is not set
The way to handle this is by enabling HIGHMEM support in the kernel or
dropping the KERNEL_START in the config. I'm haven't ever tried to
drop KERNEL_START so your milage may very on what if anything that will
break.
So, an alternative would be to leave fsl_booke_mmu.c untouched, revert
my KERNEL_START/LOWMEM mods, and instead enable HIGHMEM? Setting
HIGHMEM_START to ...? Will that entail more TLB thrashing?
Kylo
On Jun 9, 2005, at 6:25 PM, Kylo Ginsberg wrote:
On 6/9/05, Kumar Gala [off-list ref] wrote:
quoted
On Jun 9, 2005, at 5:09 PM, Kylo Ginsberg wrote:
quoted
I've modified fsl_booke_mmu.c to use a 4th TLB, thus mapping the full
1 GB of memory. However, I'm new to linux memory management, so I'd
appreciate any comments as to whether there are tradeoffs or dangers
here that I am missing.
There is a danger here in that you have left no virtual address space
for the kernel. Since KERNEL_BASE is normally 0xc000_0000 + 1G ends
up
a the end of memory. There for any devices that need virtual memory
space would not have any to map out of. I'm kinda amazed this works
at
all. I'd be interested in seeing what a boot log looks like for this
config.
Sorry, should have mentioned this in the first post. I dropped
KERNEL_BASE to 0xa0000000 and upped LOWMEM_SIZE to 0x40000000. So the
Advanced Setup portion of my .config reads:
#
# Advanced setup
#
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
CONFIG_LOWMEM_SIZE_BOOL=y
CONFIG_LOWMEM_SIZE=0x40000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xa0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_BOOT_LOAD_BOOL is not set
CONFIG_BOOT_LOAD=0x00800000
and under Platform Options:
# CONFIG_HIGHMEM is not set
quoted
The way to handle this is by enabling HIGHMEM support in the kernel or
dropping the KERNEL_START in the config. I'm haven't ever tried to
drop KERNEL_START so your milage may very on what if anything that
will
break.
So, an alternative would be to leave fsl_booke_mmu.c untouched, revert
my KERNEL_START/LOWMEM mods, and instead enable HIGHMEM? Setting
HIGHMEM_START to ...? Will that entail more TLB thrashing?
You have to set HIGHMEM_START to something. I think the default is
fine. It only means more TLB thrasing if the kernel has to touch one
of the pages in HIGHMEM. If its only application code that is using
memory > 768M then you shouldn't really see any performance impact.
either solution should work, it just depends on what you want to
accomplish at the end.
- kumar