[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180322093605.51b067fe@gandalf.local.home>
Date: Thu, 22 Mar 2018 09:36:05 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alexei Starovoitov <ast@...com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
David Miller <davem@...emloft.net>,
Daniel Borkmann <daniel@...earbox.net>,
Peter Zijlstra <peterz@...radead.org>,
Network Development <netdev@...r.kernel.org>,
kernel-team <kernel-team@...com>,
Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH v2 bpf-next 4/8] tracepoint: compute num_args at build
time
On Wed, 21 Mar 2018 15:05:46 -0700
Alexei Starovoitov <ast@...com> wrote:
> Like the only reason my patch is counting till 17 is because of
> trace_iwlwifi_dev_ucode_error().
> The next offenders are using 12 arguments:
> trace_mc_event()
> trace_mm_vmscan_lru_shrink_inactive()
>
> Clearly not every efficient usage of it:
> trace_mm_vmscan_lru_shrink_inactive(pgdat->node_id,
> nr_scanned, nr_reclaimed,
> stat.nr_dirty, stat.nr_writeback,
> stat.nr_congested, stat.nr_immediate,
> stat.nr_activate, stat.nr_ref_keep,
> stat.nr_unmap_fail,
> sc->priority, file);
> could have passed &stat instead.
Yes they should have, and if I was on the Cc for that patch, I would
have yelled at them and told them that's exactly what they needed to do.
Perhaps I should add something to keep any tracepoint from having more
than 6 arguments. That should force a clean up quickly.
I think I may start doing that.
-- Steve
Powered by blists - more mailing lists