On Mon 24-02-25 13:36:50, Kalesh Singh wrote: > On Mon, Feb 24, 2025 at 8:52 AM Lorenzo Stoakes > > > > > OK, I agree the behavior you describe exists. But do you have some > > > > > real-world numbers showing its extent? I'm not looking for some artificial > > > > > numbers - sure bad cases can be constructed - but how big practical problem > > > > > is this? If you can show that average Android phone has 10% of these > > > > > useless pages in memory than that's one thing and we should be looking for > > > > > some general solution. If it is more like 0.1%, then why bother? > > > > > > > Once I revert a workaround that we currently have to avoid > fault-around for these regions (we don't have an out of tree solution > to prevent the page cache population); our CI which checks memory > usage after performing some common app user-journeys; reports > regressions as shown in the snippet below. Note, that the increases > here are only for the populated PTEs (bounded by VMA) so the actual > pollution is theoretically larger. > > Metric: perfetto_media.extractor#file-rss-avg > Increased by 7.495 MB (32.7%) > > Metric: perfetto_/system/bin/audioserver#file-rss-avg > Increased by 6.262 MB (29.8%) > > Metric: perfetto_/system/bin/mediaserver#file-rss-max > Increased by 8.325 MB (28.0%) > > Metric: perfetto_/system/bin/mediaserver#file-rss-avg > Increased by 8.198 MB (28.4%) > > Metric: perfetto_media.extractor#file-rss-max > Increased by 7.95 MB (33.6%) > > Metric: perfetto_/system/bin/incidentd#file-rss-avg > Increased by 0.896 MB (20.4%) > > Metric: perfetto_/system/bin/audioserver#file-rss-max > Increased by 6.883 MB (31.9%) > > Metric: perfetto_media.swcodec#file-rss-max > Increased by 7.236 MB (34.9%) > > Metric: perfetto_/system/bin/incidentd#file-rss-max > Increased by 1.003 MB (22.7%) > > Metric: perfetto_/system/bin/cameraserver#file-rss-avg > Increased by 6.946 MB (34.2%) > > Metric: perfetto_/system/bin/cameraserver#file-rss-max > Increased by 7.205 MB (33.8%) > > Metric: perfetto_com.android.nfc#file-rss-max > Increased by 8.525 MB (9.8%) > > Metric: perfetto_/system/bin/surfaceflinger#file-rss-avg > Increased by 3.715 MB (3.6%) > > Metric: perfetto_media.swcodec#file-rss-avg > Increased by 5.096 MB (27.1%) > > [...] > > The issue is widespread across processes because in order to support > larger page sizes Android has a requirement that the ELF segments are > at-least 16KB aligned, which lead to the padding regions (never > accessed). Thanks for the numbers! It's much more than I'd expect. So you apparently have a lot of relatively small segments? > Another possible way we can look at this: in the regressions shared > above by the ELF padding regions, we are able to make these regions > sparse (for *almost* all cases) -- solving the shared-zero page > problem for file mappings, would also eliminate much of this overhead. > So perhaps we should tackle this angle? If that's a more tangible > solution ? > > From the previous discussions that Matthew shared [7], it seems like > Dave proposed an alternative to moving the extents to the VFS layer to > invert the IO read path operations [8]. Maybe this is a move > approachable solution since there is precedence for the same in the > write path? Yeah, so I certainly wouldn't be opposed to this. What Dave suggests makes a lot of sense. In principle we did something similar for DAX. But it won't be a trivial change so details matter... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
