On Wed, Sep 4, 2019 at 8:38 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > but also for reducing > > tracing noise. Flooding the traces makes it less useful for long traces and > > post-processing of traces. IOW, the overhead reduction is a bonus. > > This is not really anything special for this tracepoint though. > Basically any tracepoint in a hot path is in the same situation and I do > not see a point why each of them should really invent its own way to > throttle. Maybe there is some way to do that in the tracing subsystem > directly. I agree. I'd rather not special-case RSS in this way, especially not with a hardcoded aggregation and thresholding configuration. It should be possible to handle high-frequency trace data point aggregation in a general way. Why shouldn't we be able to get a time series for, say, dirty pages? Or various slab counts? IMHO, any counter on the system ought to be observable in a uniform way.
