zmatt
Active Member
That's somewhat complicated, and will depend will very much depend on how the system is being used. The available memory bandwidth is shared between all subsystems that need to handle more data than fits in their local cache/sram. This means the two A15 cores, the display controller, and any video/graphics related subsystems used (SGX544, GC320, IVA-HD, maybe ISS).he was asking whether hypotherical 2GB units with half the memory bandwidth would be slower than 4GB ones with full bandwidth.
For video streams it's easy to calculate bandwidth required, e.g. 720p60 ARGB8888 is 211 MB/s, 1080p60 is 475 MB/s, YUYV is half the bandwidth of ARGB8888. The display subsystem can be compositing up to four layers total (across LCD and HDMI combined), but typically only one would be fullscreen (or two if LCD and HDMI are used simultaneously), and it can have a writeback stream e.g. for screencast.
For other subsystems I don't immediately have concrete numbers for use cases. Max theoretical bandwidth for a 128-bit port on the L3MAIN is 3.5 GB/s per direction, max 6.7 GB/s total since reads also consume some write-bandwidth (for the requests), although in practice it may be limited by how many requests in progress the initiator can have simultaneously. DSS, IVA-HD, and ISS all have a 128-bit port, SGX544 and GC320 even have two 128-bit ports each. The memory controller has two 128-bit target ports.
Some random memory microbenchmark on a single cortex-A15 core @ 1.5 GHz showed it could do 5.4 GB/s write, 4.0 GB/s read.
Max theoretical ddr3 bandwidth (read+write combined) is just under 4 GB/s per channel, 8 GB/s total.
The 2GB units built with four (4) 512MB chips should have the same memory performance of the 4GB units built with four (4) 1GB chips.
More or less. It's possible the 4GB version is slightly faster for some workloads due to the ability to keep twice as many rows open simultaneously.
The maximum virtual memory usable by a process is 2GB or 3GB depending on user/kernel split. Of course an "application" can consist of multiple processes (see e.g. chrome), and an application can use ram that's not part of its address space (disk cache).For actively 'running' tasks, the processor runs low on resources prior to the application load reaching 2GB.
lol... no. really, no.This benefit may be marginal when compared to utilizing a /swap to either the eMMC or a fast memory card.
Correct. It seems perfectly reasonable to me to include frequently accessed files (e.g. databases) as part of the working set of a process, in which case it can easily exceed the virtual memory limit.linux kernels (not all that recent - I think I started noticing this around kernel 3.2-ish) will use available quite agressively for filesystem optimisation and other stuff.
Eh, there's a lot of confusion here. Yes the MMU can map the 4GB of virtual memory to physical memory any way you like, with 4KB granularity. Using larger pages is somewhat supported by linux (see hugetblfs and transparent hugepages) and may result in memory savings and better performance, it does not affect how much memory can be mapped. The program counter is only relevant for code execution, and 2^32 bytes is still 4GB.The MMU should be able to map 4GB of memory into whatever configuration the chip wants I'd have thought, assuming it can use large enough pages. An ARM chip using 32-bit program counter should be able to address 8GB of contiguous memory per process I'd have thought.
Note that linux reserves the top 1-2GB (configurable at compilation time) of virtual memory for the kernel's memory and memory-mapped I/O.