forums.ps2dev.org

[modrobert]

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

[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]

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]

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

[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]

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.

[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]

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]

The Emperor's new 112 MiB.

[jimparis]

I don't understand what you're saying. Both logical partitions are visible and accessible.

[modrobert]

Explain to me how to do that please.

[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]

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:

[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:

[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]

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/yellowdog-6.2-ppc-DVD_20090629.iso

[jimparis]

[modrobert]

[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]

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]

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. ;)