On Tue, Sep 3, 2019 at 10:15 PM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Tue, Sep 03, 2019 at 09:51:20PM -0700, Daniel Colascione wrote: > > On Tue, Sep 3, 2019 at 9:45 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote: > > > > > > On Tue, Sep 3, 2019 at 1:09 PM Joel Fernandes (Google) > > > <joel@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > > Useful to track how RSS is changing per TGID to detect spikes in RSS and > > > > memory hogs. Several Android teams have been using this patch in various > > > > kernel trees for half a year now. Many reported to me it is really > > > > useful so I'm posting it upstream. > > > > It's also worth being able to turn off the per-task memory counter > > caching, otherwise you'll have two levels of batching before the > > counter gets updated, IIUC. > > I prefer to keep split RSS accounting turned on if it is available. Why? AFAIK, nobody's produced numbers showing that split accounting has a real benefit. > I think > discussing split RSS accounting is a bit out of scope of this patch as well. It's in-scope, because with split RSS accounting, allocated memory can stay accumulated in task structs for an indefinite time without being flushed to the mm. As a result, if you take the stream of virtual memory management system calls that program makes on one hand, and VM counter values on the other, the two don't add up. For various kinds of robustness (trace self-checking, say) it's important that various sources of data add up. If we're adding a configuration knob that controls how often VM counters get reflected in system trace points, we should also have a knob to control delayed VM counter operations. The whole point is for users to be able to specify how precisely they want VM counter changes reported to analysis tools. > Any improvements on that front can be a follow-up. > > Curious, has split RSS accounting shown you any issue with this patch? Split accounting has been a source of confusion for a while now: it causes that numbers-don't-add-up problem even when sampling from procfs instead of reading memory tracepoint data.
