Related:  issue 761467 

mlock() requires privileges to lock more than 64kB of RAM on Android.

See:
https://github.com/torvalds/linux/blob/b66484cd74706fa8681d051840fe4b18a3da40ff/mm/mlock.c#L27

and from an Android device:
$ ulimit -l
64

Beyond that, we probably have two cases:
- Either there is enough RAM, and thus we don't need to lock memory as code pages are really "sticky" in memory
- Or there is not enough of it, and the best course of action would be to reduce Chrome's code memory footprint. That's the way we are currently investigating.

I don't think we'd ever consider running mlock() as part of our code in production -- the idea is to experiment and if it helps -- then convince Android to do something similar on our behalf. So privileges would only be an issue for the experiment.

On 512MB Android Go devices we know there isn't enough RAM for everything the system is trying to run, but it's not clear that paging out Chrome during runtime is the optimal choice the OS could be making.

While I agree that the ideal solution is to reduce Chrome's code memory footprint. Once we get to the point where we cannot improve more, I think we may still be in a situation where insisting that OS page out other things first could improve our performance on startup.

I mean, it's also possible that locking pages on startup can make things worse by increasing pressure elsewhere, but it would be interesting to know.

We are currently working on providing better insights into the amount of code required to actually use Chrome.

From what we see, the kernel does indeed make questionable choices regarding code to page out, and that's something that we can influence from Chrome's code, even without mlock().
To start with, we just need to touch a given page to put it on the active list, making it less likely to be paged out.

Will share more details soon, once we have a more concrete proposal. What we are broadly looking at:
- Grouping frequently-used code together, and possibly separated from the startup code (for instance, part of base is mixed with initialization code right now)
- Grouping modules together, and advising the kernel that they are likely not going to be used (+madvise(RANDOM))
- Improving the instrumentation we have to create a steady-state orderfile that would allow us to further reduce the footprint.

All in all, it should be possible to remove 30-50% of code footprint, and thus drastically lower the number of page faults.

Note that the kernel is already very reluctant to evict code pages, meaning that eviction is a sign of severe memory pressure.

Sounds like Performance-Loading isn't a preferable label. Let me replace it with Performance-Memory so that this bug can be out from loading triage radar.

I think this should be Performance-Startup, since this tries to improve startup time.

I think this will be covered by fine-grained prefetching that lizeb@ is working on in issue 758566.