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.
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.
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.
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?
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.
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.
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".
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.
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
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?
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:
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.
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
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 ;)
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. ;)
