Unexpected memory overhead of textures on iOS

I've been investigating the memory usage of our game on iOS and run into some numbers I can't explain. All my results are gathered using the "Allocations" and "Memory Monitor" instruments from Apple's developer tools. For test purposes, all textures are 1024x1024 RGBA8 without mipmaps, with the 'Read/Write Enabled" flag off. The dynamic textures similarly have "makeNoLongerReadable" set to true when applying the pixel changes.

I'm aware of a possible iOS bug with power-of-two uncompressed textures allocating mipmaps even when mipmaps are not active for a texture; I don't see that behaviour in these tests (with an exception described below).

The dynamic textures also allocate temporary read/write pixel storage used to fill the texture. I can see these buffers created/destroyed when I change the "makeNoLongerReadable" flag, and I am not counting that in these numbers.

I am also forcing extra garbage collecting to try to exclude temporary buffers; I can't be certain this is working, however.

My tests are run with an empty scene (for a baseline measurement), 1 - 4 loaded textures, and 1 - 4 dynamically created textures. The results I get are:

                     Allocations    Total Memory
 Empty Scene:        4.13           15.89
 1 Loaded Texture:   4.37           21.18
 2 Loaded Textures:  4.41           24.82
 3 Loaded Textures:  4.44           28.94
 4 Loaded Textures:  4.47           32.89            
 1 Dynamic Texture:  4.59           25.22
 2 Dynamic Textures: 4.63           29.23
 3 Dynamic Textures: 4.66           33.25
 4 Dynamic Textures: 4.69           37.38

The tracked allocations increase as expected.

The first loaded texture seems to take ~5.3M. That would be consistent with the mipmap bug I mentioned above, yet each subsequent loaded texture only takes the expected 4M. Even worse, the first dynamic texture seems to take that ~5.3M plus an additional 4M. Each subsequent dynamic texture, however, only takes the expected 4M.

If I load 1 texture and create 1 dynamic texture, the extra allocated memory does not overlap (~6.63M extra memory), which would, I think, rule out some kind of pixel staging scratchpad. Furthermore, I'd expect any such staging area to be temporary, and the loaded textures do not allocate enough extra space for that purpose.

So what could be causing this extra overhead? Is there any way to eliminate or work around it? Some of the iOS devices we want to support are extremely memory bound so reducing any extra overhead is critical. Given the memory constraints, these extra allocations are taked upwards of 10% of our useable memory space.