On Fri 23-02-18 08:34:19, Daniel Colascione wrote:
> On Fri, Feb 23, 2018 at 12:11 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> > On Wed 21-02-18 18:49:35, Daniel Colascione wrote:
> > [...]
> >> For more context: on Android, we've historically scanned each processes's
> >> address space using /proc/pid/smaps (and /proc/pid/smaps_rollup more
> >> recently) to extract memory management statistics. We're looking at
> >> replacing this mechanism with the new /proc/pid/status per-memory-type
> >> (e.g., anonymous, file-backed) counters so that we can be even more
> >> efficient, but we'd like the counts we collect to be accurate.
> >
> > If you need the accuracy then why don't you simply make
> > SPLIT_RSS_COUNTING configurable and disable it in your setup?
>
> I considered that option, but it feels like a last resort. I think
> agreement between /proc/pid/status and /proc/pid/smaps is a
> correctness issue, and I'd prefer to fix the correctness issue
> globally.
But those counters are inherently out-of-sync because the data may be
outdated as soon as you get the data back to the userspace (except for
the trivial single threaded /proc/self/ case).
> That said, *deleting* the SPLIT_RSS_COUNTING code would be nice and
> simple. How sure are we that the per-task accounting is really needed?
I have never measured that. 34e55232e59f ("mm: avoid false sharing of
mm_counter") has _some_ numbers.
> Maybe I'm wrong, but I feel like taking page faults will touch per-mm
> data structures anyway, so one additional atomic update on the mm
> shouldn't hurt all that much.
I wouldn't be oppposed to remove it completely if it is not measureable.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
