Total memory is 131MB, not 256MB?

Investigation into how Linux on the PS3 might lead to homebrew development.

Moderators: cheriff, emoon

Post Reply
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Total memory is 131MB, not 256MB?

Post by modrobert »

The total memory (RAM) available when booting YDL 6.1 on a PS3 is roughly 131MB according to 'dmesg' output.

Code: Select all

Top of RAM: 0x8000000, Total RAM: 0x8000000
...
Memory: 96832k/131072k available (8404k kernel code, 34240k reserved, 1100k data, 472k bss, 376k init)
When dumping memory with 'cat /dev/mem >ramdump.img' this seems correct giving 134217728 bytes (0x8000000), also compiled 'memdump' which gave the same result.

However, checking with 'cat /proc/meminfo' I get:

Code: Select all

MemTotal:         215120 kB
This is also the same amount of memory shown when using the 'top' util.

Where did the missing 84MB go?

Is this part of the PS3 firmware/OS still resident in RAM somehwere?
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

IIRC, new OS partitions under the hypervisor start out with 128 MB, which is what you see in dmesg. The OS can then allocate more memory, but some will be in use by the hypervisor, and some will be used for the framebuffer in linux. You can decrease the amount of memory reserved for the framebuffer, but that will limit what resolutions you'll be able to use in linux. It is impossible to get ALL the memory because you run under the hypervisor.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

The PS3 boots with 128MiB of RAM, and the rest is hot-plugged later. That's why it says 128MiB at boot. The reason you can only get 128MiB out of /dev/mem is probably because it is a non-linear physical mapping. The contents of /proc/meminfo, and what "top" says, are the actual values. The remaining space (betwen 210MiB and 256MiB) is taken up by the kernel, video buffers, etc.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

On a PC system the BIOS provides a physical RAM map when booting linux, something like this (dmesg from a PC nearby):

Code: Select all

 BIOS-e820: 0000000000000000 - 00000000000a0000 (usable)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fffd000 (usable)
 BIOS-e820: 000000001fffd000 - 000000001ffff000 (ACPI data)
 BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
This memory, even if split in segments physically, is still possible to access via /dev/mem as one continuous chunk.

If the PS3 Linux kernel somehow know about this extra memory "hot-plugged" after the boot process without being accessible via /dev/mem, then where is it?
J.F.
Posts: 2906
Joined: Sun Feb 22, 2004 11:41 am

Post by J.F. »

The difference is the x86 is using special registers to make that memory SEEM as if it's contiguous WITHOUT using the MMU. x86 CPUs have had that for a while now. The Cell doesn't have that... at least, not that I remember. Each partition in the Cell has ONE register that sets the memory base so that memory (one single block only!) somewhere will appear to the PPE as a block addressed at 0 going to the size of the block. I suggest you get the Cell manuals and read through the section on that.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

Yes, I will do that, and more importantly read the kernel source to try and figure out how /proc/meminfo is calculated. My question initially was to avoid doing just that. ;)

Without knowing anything I can tell by clean booting ps3 linux and just using it that there is less free memory than it should be, as if something already allocated a lot, or, that it actually is 131072k to begin with which after graphics etc. infact is 96832k as the kernel suggests during boot. Looking at graphics and flash allocation according to dmesg.

Code: Select all

ps3fb videomemory: 18874368 bytes at c000000001b00000
ps3flash bounce buffer: 262144 bytes at c000000002d00000

In short, I think MemTotal in /proc/meminfo is bogus, and 'top' rely on that bogus value.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

I got a partial answer. The memory allocated by resident parts of the PS3 OS while playing games was 74mb at firmware v1.80 according to developers (Naughty Dog), assuming the same goes for "Other OS".
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

That assumption is incorrect. As explained here and elsewhere on this forum, the hypervisor creates two logical partitions, 128 MiB and 112 MiB, leaving 240 MiB accessible to Linux.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

The Emperor's new 112 MiB.
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

I don't understand what you're saying. Both logical partitions are visible and accessible.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

Explain to me how to do that please.
User avatar
mc
Posts: 211
Joined: Wed Jan 12, 2005 7:32 am
Location: Linköping

Post by mc »

The first 128M can be accessed either in real mode (using effective address 0 - 0x7ffffff), or by using the MMU to map LPAR address 0 - 0x7ffffff to some virtual address range of your choice (see lv1_write_htab_entry et al).

The remaining 112M can be allocated using the lv1_allocate_memory HV call. The call will return an LPAR address X, and by mapping the LPAR address range X - X+0x6ffffff to some virtual address range, you can access it. This part of the memory can not be accessed in real mode.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

Ok, so if I understand this correctly; under ps3 linux (YDL 6.1, which was my initial question) any C code just using malloc() or calloc() will never allocate memory in this 112M segment unless specifically programmed to do so?


BTW:

/proc/iomem looks like this:

Code: Select all

08000000-0effffff : System RAM
4000001c0000-4000001cffff : ohci_hcd
4000001d0000-4000001dffff : ohci_hcd
4000001e0000-4000001effff : ehci_hcd
4000001f0000-4000001fffff : ehci_hcd
User avatar
mc
Posts: 211
Joined: Wed Jan 12, 2005 7:32 am
Location: Linköping

Post by mc »

Well, what Linux does with it is a question which might be better asked in the Linux forum.

With a 2.6.28.10 kernel at least, the 112M gets added to the regular memory pool so that you can malloc() from them:

Code: Select all

miu:~% uname -a
Linux miu 2.6.28.10 #1 SMP Sun Jul 5 12:11:51 CEST 2009 ppc64 Cell Broadband Engine, altivec supported GNU/Linux
miu:~% cat /proc/meminfo | head -1
MemTotal:         228440 kB
miu:~%


(the "missing" 17M are used by the kernel.)
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

This is kernel 2.6.27. Anyway, back to square one (or my first post in this thread rather). Thanks for the help.

If any admin read this, please move the thread to the PS3 linux forum.
speedxl
Posts: 24
Joined: Thu Aug 07, 2008 5:39 am

Post by speedxl »

YDL 6.2 uses kernel v2.6.29 (64 bit), between other upgrades that boost performance, you can download it now from the public mirrors, this is one location:

http://mirror.anl.gov/yellowdog/iso/yel ... 090629.iso
jimparis
Posts: 1145
Joined: Fri Jun 10, 2005 4:21 am
Location: Boston

Post by jimparis »

modrobert wrote:This is kernel 2.6.27. Anyway, back to square one (or my first post in this thread rather).
No, we're not back to square one, you're just not listening.
On Linux, 128MiB is available immediately and the additional 112MiB is hotplugged during the boot process. All 240MiB is available to applications. It all works.
/proc/iomem looks like this:
08000000-0effffff : System RAM
Do the math. That's the extra 112MiB, as registered by the memory hotplug subsystem.
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

jimparis wrote:
/proc/iomem looks like this:
08000000-0effffff : System RAM
Do the math. That's the extra 112MiB, as registered by the memory hotplug subsystem.
You are wrong. That is the initial RAM, check the 'dmesg' output.
User avatar
mc
Posts: 211
Joined: Wed Jan 12, 2005 7:32 am
Location: Linköping

Post by mc »

He is not wrong. The initial RAM has LPAR address 0-0x7ffffff. Note that the dmesg printout relating to the initial RAM gives the _top_ address of RAM (0x7ffffff+1), not the start of it.
Flying at a high speed
Having the courage
Getting over crisis
I rescue the people
modrobert
Posts: 15
Joined: Tue Apr 12, 2005 4:32 pm
Location: Bangkok
Contact:

Post by modrobert »

Ok, my mistake, I was wrong. It is starting to make sense now (after checking memory_hotplug.c in the kernel source). Still, I don't get the "112MiB math part", is the address range in /proc/iomem wrong?

0effffff-08000000 = 6FFFFFF (117440511 Bytes)


EDIT:

Never mind, a Mebibyte is 1,048,576... should be Meh-bibyte ;)
Arwin
Posts: 426
Joined: Tue Jul 12, 2005 7:00 pm

Post by Arwin »

Two tips:

1. Install YDL 6.2 if you can. Better and faster, as far as I can tell, and it has the (50%) faster PS3VRAM from the RSX chip installed by default, as well as the 3.1 Cell SDK

2. Assume Jimparis is never wrong. It's a pretty safe assumption. ;)
Post Reply