On Fri, Feb 23, 2018 at 9:50 AM, Michal Hocko <mhocko@xxxxxxxxxx> wrote:
> 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
>> >> 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).
It's one thing to be inconsistent for a moment because two cores and
doing things at the same time. It's another thing to be inconsistent
for a week. :-)
>
>> 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.
Just deleting SPLIT_RSS_COUNTING is certainly my preferred option. I
didn't see any benchmarks accompanying the inclusion of the mechanism
in the first place. How would you suggest verifying that we can safely
delete it? I *think* it would have the greatest benefit on very large
systems with lots of tasks sharing and mm, each taking page faults
often, but I don't have any such large machines.
--
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>
