10 Things that "Absolutely suck" about the iPhone. (Yes I have one)

[cmaier]

Won't give up, eh? You should probably PM him - sounded like he doesn't regularly check the text of the thread.

By the way, what you call "suspicious" I call "good OS/hardware design." If you add up the used memory, the working set fits well within physical memory; in any device it's certainly a goal to keep the working set smaller than physical memory to avoid paging.

Note, too, that if the OS didn't have virtual memory (i.e.: if they actually went to the trouble to strip it out of the OS, because it certainly exists in OS X from which this OS derives), it would be pretty silly for them to leave in the posix hooks which allow querying virtual memory usage (and always returning 0) - particularly silly since your theory, i believe, is that they'll never allow software other than their own, and thus no one should ever have been able to run top or ps.

I just ran "top" on my windows laptop. It's using 106076k swap even with nothing going on. Sweet.

 

[surur]

I just ran "top" on my windows laptop. It's using 106076k swap even with nothing going on. Sweet.

Thats the point, isn't it. When a system is optimized it swaps pages even before they need to be swapped, so that you dont spend time churning swapping things while waiting to fulfill a request for RAM.

As this seem a rather simple way to check whats going on, why not do it?

Surur

 

[Mike Overbo]

Swapfile is usually located in /private/var/vm with OSX; that directory is empty on the iPhone. It doesn't look like they're using traditional swap, they've replaced swap outright with cacheing. So Surur, it looks like your suspicion is justified there. That's also probably why swapins aren't being reported in 'top', as that's part of the 3rd party development toolkit. I'm still digging.

# df -k
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/disk0s1 307200 199324 104804 66% /
devfs 18 18 0 100% /dev
/dev/disk0s2 3657400 11972 3645428 1% /private/var
#

omghax:root /System/Library/Caches/com.apple.kernelcaches# ls -al
total 6376
drwxr-xr-x 4 root wheel 136 Aug 15 13:34 .
drwxr-xr-x 3 root wheel 102 Aug 15 13:33 ..
-rw-r--r-- 1 root wheel 3261992 Aug 15 13:34 kernelcache.release.s5l8900xrb
-rw-r--r-- 1 root wheel 3261992 Aug 15 13:34 kernelcache.s5l8900xrb
omghax:root /System/Library/Caches/com.apple.kernelcaches#

I'm not sure if the value below is in bytes, kilobytes, or 512b blocks.

omghax:root /# cat /tmp/MediaCache/diskcacherepository.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>checkedinlist</key>
<dict/>
<key>checkedoutlist</key>
<dict/>
<key>targetsize</key>
<integer>10485760</integer>
</dict>
</plist>
omghax:root /#

 

[cmaier]

What shows up in /dev? The "caching" is to flash, so same difference. (Caching is also done in pages. The primary difference between cache and VM is that VM uses virtual addressing while cache uses physical addressing.)

Do you have the toolchain set up? If so, this code should tell us a lot:

main() {
int *buffer=malloc(256000000);
printf("%ld",(long)buffer);
}

 

[cmaier]

Just looked up how the OSX kernel cache works. Looks like it's in the same place as the desktop. Not sure what, exactly, it does on the iphone since it can't provide a speed benefit (on the desktop you are moving stuff from disk to DRAM. On iphone it just moves from flash to flash). I wonder if they just added address-translation to the cache.

Perhaps /private/var/ only gets a swap file when there's something swapped out?

 

[Mike Overbo]

Still no luck on finding a swapfile. Here's the virtual memory framework (a framework is basically a kernel extension)

# pwd
/System/Library/PrivateFrameworks/vmutils.framework
# ls
total 380
drwxr-xr-x 4 root wheel 136 Aug 15 21:26 .
drwxr-xr-x 7 root wheel 238 Aug 15 23:34 ..
-rw-r--r-- 1 root wheel 834 Jun 21 02:26 Info.plist
-rwxr-xr-x 1 root wheel 384844 Aug 15 21:26 vmutils
# less vmutils
"vmutils" may be a binary file. See it anyway?
#

The iPhone doesn't have the 'strings' command, but my mac does. I copied vmutils over and ran strings on it, the results are available here. It's about 1/2 the size of the mac vmutils binary. I don't have the ability to view VM map regions; there's no port of the 'vmmap' command to the acorn architecture yet.

 

[cmaier]

There are a lot of "page" references in vmutils, as well as references to vm regions. Whatever is going on, they sure left a lot of vm-related code lying around.

 

[Mike Overbo]

What shows up in /dev? The "caching" is to flash, so same difference. (Caching is also done in pages. The primary difference between cache and VM is that VM uses virtual addressing while cache uses physical addressing.)

Do you have the toolchain set up? If so, this code should tell us a lot:

main() {
int *buffer=malloc(256000000);
printf("%ld",(long)buffer);
}

Sorry, I don't have the toolchain set up.


here are the files in /dev:

bpf0 bpf1 btreset console cu.baseband cu.bluetooth cu.debug cu.iap disk0 disk0s1 disk0s2 h5.baseband klog mrvl868x0 null ptmx ptyp0 ptyp1 ptyp2 ptyp3 ptyp4 ptyp5 ptyp6 ptyp7 random rdisk0 rdisk0s1 rdisk0s2 sdio tty tty.baseband tty.bluetooth tty.debug tty.iap ttyp0 ttyp1 ttyp2 ttyp3 ttyp4 ttyp5 ttyp6 ttyp7 uart.baseband uart.bluetooth uart.debug uart.iap urandom vn0 vn1 zero

 

[surur]

Swapping is very uncommon on embedded devices, and swapping to NAND is generally not a good idea, due to wear and tear on the memory cells.

Of course I am sure the individual apps cache things all the time, like ipod caching album covers, but the kind of automatic page swapping we are used to on our desktops would have really surprised me.

Surur

 

[cmaier]

Thats the point, isn't it. When a system is optimized it swaps pages even before they need to be swapped, so that you dont spend time churning swapping things while waiting to fulfill a request for RAM.

As this seem a rather simple way to check whats going on, why not do it?

Surur

No - "swapped" means to disk. An optimized system keeps things in RAM until the last possible moment. Some systems will write to disk to avoid the write-before-read delay, but the "most optimum" strategy depends entirely on the nature of the code you are actually running.

 

[cmaier]

Swapping is very uncommon on embedded devices, and swapping to NAND is generally not a good idea, due to wear and tear on the memory cells.

Of course I am sure the individual apps cache things all the time, like ipod caching album covers, but the kind of automatic page swapping we are used to on our desktops would have really surprised me.

Surur

I've never had NAND die due to too many writes, but I've had lots of hard drives die (Just this week, in fact. Don't get me started).

The caching referenced above is kernel caching, not application caching. The caching to which you refer is the normal sort of caching where things are kept in primary RAM. Ideally, you'd always have what you need in RAM, but cache replacement algorithms can only guess, so a typical strategy is to remove the "least-recently-used" cache page. The kernel cache file is on flash, not in DRAM, so it's an entirely different sort of beast. Typically each level of cache would be on the order of 1/4 slower and 4x the size of the prior level. The kernel cache uses "mass storage" (flash), which is another thing that makes it a different puppy than what most people mean by cache (which uses special S or D-RAM). For example, I'm sure that the microprocessor has some amount of built-in SRAM cache.

The kernel extension is definitely referring to page swapping (at least the strings exist), but, I agree, there's one sure way to tell - in the end, the question is whether user-space software can access more than physical DRAM. We know the chip has a page-translation table, that the OS has, at the least, hooks to support VM, and that repeated-writes don't scare the iphone designers because they use kernel caching. Still missing the smoking gun, however. I wish I was at my old job still - I'd know exactly what is going on by now.

 

[Mike Overbo]

The virtual memory subsystem is definitely actively loaded in the kernel. However, the command that OSX uses to manage swap files, dynamic_pager, isn't present on the file system.

# sysctl -a | grep page
kern.exec: unknown type returned
hw.pagesize = 4096
hw.pagesize: 4096
# sysctl -a | grep vm
kern.exec: unknown type returned
vm.loadavg: 0.00 0.03 0.06
vm.swapusage: total = 0.00M used = 0.00M free = 0.00M
kern.ipc.sorecvmincopy: 16384
vm.shared_region_trace_level: 1
#



# find / -name \*cache\* -print
/System/Library/Caches/com.apple.kernelcaches
/System/Library/Caches/com.apple.kernelcaches/kernelcache.release.s5l8900xrb
/System/Library/Caches/com.apple.kernelcaches/kernelcache.s5l8900xrb
/private/var/root/Library/Caches/Installer/01/06/2500720918-2617165156.cache
/private/var/root/Library/Caches/Installer/01/10/1848017171-3461688743.cache
/private/var/root/Library/Caches/Installer/07/12/2529086589-1956845263.cache
/private/var/root/Library/Caches/Installer/10/03/3389948324-1565180464.cache
/private/var/root/Library/Caches/Installer/12/13/3716575171-2969581017.cache
/private/var/tmp/MediaCache/diskcacherepository.plist
# find / -name \*Cache\* -print
/Library/Caches
/System/Library/Caches
/System/Library/Extensions/Caches
/System/Library/Fonts/CGFontCache.plist
/System/Library/Fonts/Cache
/private/var/root/Library/Caches
/private/var/root/Library/YouTube/VideoCache
/private/var/tmp/MediaCache
#

It's worth mentioning that a lot of the boot files are hidden. For example the kernel, which I hope I may presume is on the iPhone somewhere, cannot be found: it's simply not in this filesystem. I had hoped I'd see something interesting in the NVRAM settings, but no (note the absence of values for boot-args and boot-partition):


# nvram -p
auto-boot true
bootdelay 0
backlight-level 12
filesize 14474
boot-args
boot-partition
#

 

[cmaier]

load average is low. The fact that hw.pagesize is set certainly hints that vm is active.

Nothing you do causes a pagefault? maybe watching a big movie while loading a few giant pdfs or something?

 

[cmaier]

Can you run sysctl | grep mem ? That should tell us usermem and physmem.

 

[Mike Overbo]

I've had no pagefaults. After reading the iPhoneDevWiki, some system files are stored on the boot ramdisk, which is why I can't find them on the file system.


# sysctl -a | grep mem
kern.exec: unknown type returned
hw.physmem = 121634816
hw.usermem = 100073472
hw.memsize = 121634816
kern.memorystatus_level: 70
kern.memorystatus_kev_failure_count: 0
hw.memsize: 121634816
hw.memfrequency: 133333333
hw.memfrequency_min: 133333333
hw.memfrequency_max: 133333333
#

 

[cmaier]

Unless the ramdisk is in flash, the pagefile can't reside there.

 

[Mike Overbo]

I've been doing my memory tests with safari. I can have 6-7 rather large pages open (fark photoshop thread, nytimes, asia times, sfgate, allthingsd, etc). I've got top reporting less than 1 MB remaining, all pages except the page I'm viewing are cleared from memory (which clears up about 20MB of memory). The next time I visit those other tabs, the page is reloaded over the internet. Closing the pages altogether clears up about another 10MB or so.

VM is definitely loaded and running in the kernel, but I've got no swapfiles, and it's not letting me allocate more than what's available in RAM. Why both top and ps report page ins is a mystery to me, unless they're using the pagefile to determine what processes to kill when physical memory runs out. But that's just a wild guess, I'm not by any means a kernel hacker.

cmaier, I've read that the missing amounts of memory (about 10mb missing) function as shared memory for the graphics card, btw.

 

[cmaier]

Yeah, pagebuffer for graphics makes sense.

Sounds like the memory management is VM plus extra aggression. The way those backgrounded tabs are handled seems like a bad engineering decision to me.

To convince surur we probably need to load a single page > 120MB.

 

[surur]

Actually it looks like no VM at all. I guess you will end up having to say Apple has been "silly" after all for following industry standards.

Surur

 

[cmaier]

Actually it looks like no VM at all. I guess you will end up having to say Apple has been "silly" after all for following industry standards.

Surur

Dude, let us get some better tests. You are ignoring all the other evidence and focussing on the one datapoint where safari dumps tabs? For all we know that's a limitation in the pagebuffers used for rendering the webpages and not RAM. (BTW - I'm assuming those other tabs really load off the net again, and you aren't just seeing them re-render?)