Re: Does file-mapping a memory allocation work around RAM limits?

[Rick Mann]

Thanks for that thorough explanation! We're going to try using mmap(). It will 
be interesting to do this from Swift.


> On May 4, 2017, at 10:04 , David Duncan  wrote:
> 
> 
>> On May 3, 2017, at 11:51 PM, Rick Mann  wrote:
>> 
>>> 
>>> On May 3, 2017, at 23:27 , Doug Hill  wrote:
>>> 
>>> 
 On May 3, 2017, at 6:21 PM, Rick Mann  wrote:
 
 Our iOS app works with very large data buffers (hundreds of MB). As you 
 can imagine, we run into issues at times.
 
 I saw some sample code that used this technique, and it got me wondering 
 if this actually works around the 600 MB limitation of some iOS devices 
 (which begs another question: doss the large iPad Pro with 3GB of RAM also 
 limit apps to 600 MB?).
 
 -- 
 Rick Mann
 rm...@latencyzero.com
>>> 
>>> The limits of mmap should be the limits of the file system. Well, 
>>> technically it’s limited by the size_t parameter which I guess is OS 
>>> specific. But these days it should be what the VFS can handle.
>>> 
>>> I just tried out this code snippet:
>>> 
>>> http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/
>>>  
>>> 
>>> 
>>> and set the size of the mapped file to 32GB Works fine on a Mac with 16GB 
>>> of RAM.
>>> 
>>> It is SLOOWW however. You have to move all that data across a bus 
>>> after all. If you need to load 3GB of data from your file, I recommend 
>>> making it happen on a background thread. And make some lights blink and 
>>> play a happy tune while the user waits.
>>> 
>>> Not sure what the limitation on some iOS devices you’re referring to. Is it 
>>> dependent on the installed RAM? Are there other artificial limits?
>> 
>> Yeah, at least on 1 GB iOS devices, apps are limited to 600 MB (even if 
>> there's more available). I think there are subtleties to that (e.g. maybe 
>> texture memory isn't counted), I'm not sure.
> 
> iOS tracks memory per-process primarily in 3 buckets – Dirty, Resident, and 
> Virtual. The hierarchy is also in that order, all Dirty memory is Resident, 
> and all Resident memory is Virtual. Virtual just means that address space is 
> allocated – there is a hard limit on this that is below the theoretical 
> address space (significantly so in the case of iOS), in the 2-4GB range (may 
> vary by device installed memory, but I don’t recall). Resident memory is 
> memory that has physical RAM allocated to it and so the CPU can manipulate 
> it. This is the 600MB limit that you mentioned (at least on 1GB devices, 
> again I don’t recall if it is different or what it is on larger devices). 
> Dirty memory is memory that has been written to. Because iOS does not have a 
> demand paging memory system, this memory typically has no where to go if you 
> hit the Resident memory limits.
> 
> This is where mmap() comes into play – it allows you to create a Virtual 
> allocation, whose Resident memory is backed by a file, just like in a demand 
> paged system. So you can write to that memory, and if your app uses too much 
> memory, the OS can attempt to recover by writing it to disk on your behalf 
> (turning Resident-Dirty memory into Virtual). Sweet right?
> 
> But remember that hard Virtual limit I mentioned earlier – that means that if 
> you try to mmap() too much you end up running out of Virtual memory, and 
> you’ll likely get abort()’d by some subsystem attempting to allocate memory.
> 
> And so even though iOS is a 64-bit OS, due to other performance 
> considerations, the virtual address space is more akin to a 32-bit OS. This 
> is of course an implementation detail that can be expanded in the future, but 
> something to keep in mind if you plan to use mmap() a lot.
> 
> From the sounds of what our app does, keeping around a single mmap()’s 
> scratch space may be reasonable. You probably still want to keep it at a 
> modest size, but it should help you process those large data buffers without 
> getting your app killed.
> --
> David Duncan
> 


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does file-mapping a memory allocation work around RAM limits?

[David Duncan]

> On May 3, 2017, at 11:51 PM, Rick Mann  wrote:
> 
>> 
>> On May 3, 2017, at 23:27 , Doug Hill  wrote:
>> 
>> 
>>> On May 3, 2017, at 6:21 PM, Rick Mann  wrote:
>>> 
>>> Our iOS app works with very large data buffers (hundreds of MB). As you can 
>>> imagine, we run into issues at times.
>>> 
>>> I saw some sample code that used this technique, and it got me wondering if 
>>> this actually works around the 600 MB limitation of some iOS devices (which 
>>> begs another question: doss the large iPad Pro with 3GB of RAM also limit 
>>> apps to 600 MB?).
>>> 
>>> -- 
>>> Rick Mann
>>> rm...@latencyzero.com
>> 
>> The limits of mmap should be the limits of the file system. Well, 
>> technically it’s limited by the size_t parameter which I guess is OS 
>> specific. But these days it should be what the VFS can handle.
>> 
>> I just tried out this code snippet:
>> 
>> http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/
>>  
>> 
>> 
>> and set the size of the mapped file to 32GB Works fine on a Mac with 16GB of 
>> RAM.
>> 
>> It is SLOOWW however. You have to move all that data across a bus 
>> after all. If you need to load 3GB of data from your file, I recommend 
>> making it happen on a background thread. And make some lights blink and play 
>> a happy tune while the user waits.
>> 
>> Not sure what the limitation on some iOS devices you’re referring to. Is it 
>> dependent on the installed RAM? Are there other artificial limits?
> 
> Yeah, at least on 1 GB iOS devices, apps are limited to 600 MB (even if 
> there's more available). I think there are subtleties to that (e.g. maybe 
> texture memory isn't counted), I'm not sure.

iOS tracks memory per-process primarily in 3 buckets – Dirty, Resident, and 
Virtual. The hierarchy is also in that order, all Dirty memory is Resident, and 
all Resident memory is Virtual. Virtual just means that address space is 
allocated – there is a hard limit on this that is below the theoretical address 
space (significantly so in the case of iOS), in the 2-4GB range (may vary by 
device installed memory, but I don’t recall). Resident memory is memory that 
has physical RAM allocated to it and so the CPU can manipulate it. This is the 
600MB limit that you mentioned (at least on 1GB devices, again I don’t recall 
if it is different or what it is on larger devices). Dirty memory is memory 
that has been written to. Because iOS does not have a demand paging memory 
system, this memory typically has no where to go if you hit the Resident memory 
limits.

This is where mmap() comes into play – it allows you to create a Virtual 
allocation, whose Resident memory is backed by a file, just like in a demand 
paged system. So you can write to that memory, and if your app uses too much 
memory, the OS can attempt to recover by writing it to disk on your behalf 
(turning Resident-Dirty memory into Virtual). Sweet right?

But remember that hard Virtual limit I mentioned earlier – that means that if 
you try to mmap() too much you end up running out of Virtual memory, and you’ll 
likely get abort()’d by some subsystem attempting to allocate memory.

And so even though iOS is a 64-bit OS, due to other performance considerations, 
the virtual address space is more akin to a 32-bit OS. This is of course an 
implementation detail that can be expanded in the future, but something to keep 
in mind if you plan to use mmap() a lot.

From the sounds of what our app does, keeping around a single mmap()’s scratch 
space may be reasonable. You probably still want to keep it at a modest size, 
but it should help you process those large data buffers without getting your 
app killed.
--
David Duncan

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does file-mapping a memory allocation work around RAM limits?

[Alastair Houghton]

To answer the OP’s original question, I’m not sure about the exact rules Apple 
is using on iOS, but I’d expect the memory limit to apply to *private* memory, 
namely that allocated using malloc() et al, plus dirty pages mapped with 
mmap()’s MAP_PRIVATE flag.  Read-only and shared mappings that are backed by a 
file or by swap wouldn’t count; nor would non-dirty pages mapped with 
MAP_PRIVATE, because in all of those cases the data can be purged from RAM and 
retrieved from storage (disk or Flash) when needed.

On 4 May 2017, at 07:27, Doug Hill  wrote:
> 
> The limits of mmap should be the limits of the file system. Well, technically 
> it’s limited by the size_t parameter which I guess is OS specific. But these 
> days it should be what the VFS can handle.

It’s limited by:

- The length of files allowed by the filesystem
- Available, suitably aligned, contiguous address space in the virtual memory 
map
- Available space in the page table (usually this shouldn’t be an issue on 
normal operating systems)

size_t is generally specified to be the same width as a pointer on the target 
architecture - otherwise it would unnecessarily restrict all kinds of things.  
Strictly speaking, the C standard only requires that size_t be at least 16 bits 
in size (and says it’s the type of the result of the sizeof operator), but in 
practice on a 32-bit machine it’ll be 32-bit, and on a 64-bit machine it’ll be 
64-bit.  AFAIK the only time things might get complicated is if you were 
dealing with hairy old segmented x86 code, which you aren’t.

Note that the filesystem may well allow files larger than the address space, 
particularly on 32-bit systems.  That isn’t necessarily a problem - you cannot, 
after all, mmap() more of the file than you have address space, and if you are 
particularly set on using mmap() even in that case you can use the “offset” 
argument to choose which part of the data you’re mapping in.

On a 64-bit system, mmap() is a reasonable thing to do even for large files.  
On a 32-bit system, I’d steer clear of using mmap() for anything large; it 
still has its uses, but you can run out of address space too easily.

Kind regards,

Alastair.

--
http://alastairs-place.net

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does file-mapping a memory allocation work around RAM limits?

[Rick Mann]

> On May 3, 2017, at 23:27 , Doug Hill  wrote:
> 
> 
>> On May 3, 2017, at 6:21 PM, Rick Mann  wrote:
>> 
>> Our iOS app works with very large data buffers (hundreds of MB). As you can 
>> imagine, we run into issues at times.
>> 
>> I saw some sample code that used this technique, and it got me wondering if 
>> this actually works around the 600 MB limitation of some iOS devices (which 
>> begs another question: doss the large iPad Pro with 3GB of RAM also limit 
>> apps to 600 MB?).
>> 
>> -- 
>> Rick Mann
>> rm...@latencyzero.com
> 
> The limits of mmap should be the limits of the file system. Well, technically 
> it’s limited by the size_t parameter which I guess is OS specific. But these 
> days it should be what the VFS can handle.
> 
> I just tried out this code snippet:
> 
> http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/
>  
> 
> 
> and set the size of the mapped file to 32GB Works fine on a Mac with 16GB of 
> RAM.
> 
> It is SLOOWW however. You have to move all that data across a bus 
> after all. If you need to load 3GB of data from your file, I recommend making 
> it happen on a background thread. And make some lights blink and play a happy 
> tune while the user waits.
> 
> Not sure what the limitation on some iOS devices you’re referring to. Is it 
> dependent on the installed RAM? Are there other artificial limits?

Yeah, at least on 1 GB iOS devices, apps are limited to 600 MB (even if there's 
more available). I think there are subtleties to that (e.g. maybe texture 
memory isn't counted), I'm not sure.


-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Does file-mapping a memory allocation work around RAM limits?

[Doug Hill]

> On May 3, 2017, at 6:21 PM, Rick Mann  wrote:
> 
> Our iOS app works with very large data buffers (hundreds of MB). As you can 
> imagine, we run into issues at times.
> 
> I saw some sample code that used this technique, and it got me wondering if 
> this actually works around the 600 MB limitation of some iOS devices (which 
> begs another question: doss the large iPad Pro with 3GB of RAM also limit 
> apps to 600 MB?).
> 
> -- 
> Rick Mann
> rm...@latencyzero.com

The limits of mmap should be the limits of the file system. Well, technically 
it’s limited by the size_t parameter which I guess is OS specific. But these 
days it should be what the VFS can handle.

I just tried out this code snippet:

http://www.linuxquestions.org/questions/programming-9/mmap-tutorial-c-c-511265/ 


and set the size of the mapped file to 32GB Works fine on a Mac with 16GB of 
RAM.

It is SLOOWW however. You have to move all that data across a bus after 
all. If you need to load 3GB of data from your file, I recommend making it 
happen on a background thread. And make some lights blink and play a happy tune 
while the user waits.

Not sure what the limitation on some iOS devices you’re referring to. Is it 
dependent on the installed RAM? Are there other artificial limits?

Doug Hill
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Does file-mapping a memory allocation work around RAM limits?

[Rick Mann]

Our iOS app works with very large data buffers (hundreds of MB). As you can 
imagine, we run into issues at times.

I saw some sample code that used this technique, and it got me wondering if 
this actually works around the 600 MB limitation of some iOS devices (which 
begs another question: doss the large iPad Pro with 3GB of RAM also limit apps 
to 600 MB?).

-- 
Rick Mann
rm...@latencyzero.com


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com