Looking at pagecache page-in offsets has been always in my low-priority list as something to ensure that access is actually sequential in the beginning. It's been low priority because it requires some kernel-fu, additionally page-by-page analysis on top of that (with some expected IO-randomness shortly after messageloop start).

So I was not sure what are benefits, beyond nice graphs like Firefox had with their ordering..

Do you have a trace that shows this?
It might be related to a change I made during the hackathon (only prefetch the ordered section of code).

Outside this, knowing which symbols we call is fairly easy, by running with an instrumented binary (that we use to generate the orderfile), and collecting the resulting profile. There is some distortion from the instrumentation runtiome (fairly small) and size (>5M) overhead, but at least you get the full list.

Note that this will overestimate the issue, as the prefetcher is typically done a couple 100s of ms after library load, and then we no longer have major page faults for code.

This trace was taken from the Wednesday build during the hackathon:

https://drive.google.com/open?id=1gmb-p64UofCJOtw-zllPYpIcammeHAVi

This one was from the unmodified Monday build:

https://drive.google.com/open?id=1IWL1Szjncf6L7zCKaeSE5IHT7a3MeZ39

(Warning: both are O(100M) :)

Thanks for the tip about using an instrumented build to get the faulting symbols!

Both traces are from a 512MB device. IIRC the IO is less severe on 1GB.

Available, but no owner or component? Please find a component, as no one will ever find this without one.