Mapping full 1 GB of memory on a Freescale Book E part

Mapping full 1 GB of memory on a Freescale Book E part

[Kylo Ginsberg]

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

Re: Mapping full 1 GB of memory on a Freescale Book E part

[Kumar Gala]

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

Re: Mapping full 1 GB of memory on a Freescale Book E part

[Kylo Ginsberg]

On 6/9/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>=20
> On Jun 9, 2005, at 5:09 PM, Kylo Ginsberg wrote:
> > 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

Re: Mapping full 1 GB of memory on a Freescale Book E part

[Kumar Gala]

On Jun 9, 2005, at 6:25 PM, Kylo Ginsberg wrote:

> On 6/9/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>>
>> On Jun 9, 2005, at 5:09 PM, Kylo Ginsberg wrote:
>>> 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
>
>> 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