[Add Steven] On Wed 04-09-19 12:28:08, Joel Fernandes wrote: > On Wed, Sep 4, 2019 at 11:38 AM Michal Hocko <mhocko@xxxxxxxxxx> wrote: > > > > On Wed 04-09-19 11:32:58, Joel Fernandes 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 am not sure if there is a way to do this easily. Add to that, the fact that > you still have to call into trace events. Why call into it at all, if you can > filter in advance and have a sane filtering default? > > The bigger improvement with the threshold is the number of trace records are > almost halved by using a threshold. The number of records went from 4.6K to > 2.6K. Steven, would it be feasible to add a generic tracepoint throttling? -- Michal Hocko SUSE Labs
