{"push_id":2954394820,"size":1,"distinct_size":1,"ref":"refs/heads/lineage-16.0","head":"0be659c1feeba1d3213ab6aadfaa3ee79290f26f","before":"c7f8f874be8cc1a16bf1eb788f69f1c3db4226bd","commits":[{"sha":"0be659c1feeba1d3213ab6aadfaa3ee79290f26f","author":{"name":"Daniel Colascione","email":"0eacd3f62da61bf475a16286f0a7936f16b95b89@google.com"},"message":"Add /proc/pid/smaps_rollup\n\n/proc/pid/smaps_rollup is a new proc file that improves the\nperformance of user programs that determine aggregate memory\nstatistics (e.g., total PSS) of a process.\n\nAndroid regularly \"samples\" the memory usage of various processes in\norder to balance its memory pool sizes. This sampling process involves\nopening /proc/pid/smaps and summing certain fields. For very large\nprocesses, sampling memory use this way can take several hundred\nmilliseconds, due mostly to the overhead of the seq_printf calls in\ntask_mmu.c.\n\nsmaps_rollup improves the situation. It contains most of the fields of\n/proc/pid/smaps, but instead of a set of fields for each VMA,\nsmaps_rollup instead contains one synthetic smaps-format entry\nrepresenting the whole process. In the single smaps_rollup synthetic\nentry, each field is the summation of the corresponding field in all\nof the real-smaps VMAs. Using a common format for smaps_rollup and\nsmaps allows userspace parsers to repurpose parsers meant for use with\nnon-rollup smaps for smaps_rollup, and it allows userspace to switch\nbetween smaps_rollup and smaps at runtime (say, based on the\navailability of smaps_rollup in a given kernel) with minimal fuss.\n\nBy using smaps_rollup instead of smaps, a caller can avoid the\nsignificant overhead of formatting, reading, and parsing each of a\nlarge process's potentially very numerous memory mappings. For\nsampling system_server's PSS in Android, we measured a 12x speedup,\nrepresenting a savings of several hundred milliseconds.\n\nOne alternative to a new per-process proc file would have been\nincluding PSS information in /proc/pid/status. We considered this\noption but thought that PSS would be too expensive (by a few orders of\nmagnitude) to collect relative to what's already emitted as part of\n/proc/pid/status, and slowing every user of /proc/pid/status for the\nsake of readers that happen to want PSS feels wrong.\n\nThe code itself works by reusing the existing VMA-walking framework we\nuse for regular smaps generation and keeping the mem_size_stats\nstructure around between VMA walks instead of using a fresh one for\neach VMA.  In this way, summation happens automatically.  We let\nseq_file walk over the VMAs just as it does for regular smaps and just\nemit nothing to the seq_file until we hit the last VMA.\n\nBenchmarks:\n\n    using smaps:\n    iterations:1000 pid:1163 pss:220023808\n    0m29.46s real 0m08.28s user 0m20.98s system\n\n    using smaps_rollup:\n    iterations:1000 pid:1163 pss:220702720\n    0m04.39s real 0m00.03s user 0m04.31s system\n\nSigned-off-by: Daniel Colascione <dancol@google.com>\n\nBug: 63439864\nChange-Id: I4af852034c014f9d606060649207f8a1eb3d2702","distinct":true,"url":"https://api.github.com/repos/Planet-X/android-kernel-zenfone3_advanced/commits/0be659c1feeba1d3213ab6aadfaa3ee79290f26f"}]}
{"actor":{"display_login":"Planet-X"}}