Ben Pfaff <b...@ovn.org> wrote on 05/20/2016 12:13:46 AM:
> From: Ben Pfaff <b...@ovn.org>
> To: Ryan Moats/Omaha/IBM@IBMUS
> Cc: discuss <discuss@openvswitch.org>
> Date: 05/20/2016 12:14 AM
> Subject: Re: [ovs-discuss] Instrumenting OVN
>
> On Thu, May 19, 2016 at 05:51:19PM -0500, Ryan Moats wrote:
> >
> > As I mentioned at today's IRC meeting - we have a need to include
measuring
> > the performance of the OVN control channel under scale as part of our
CI/CD
> > test suite, which is driving us to examine the feasibility of some sort
of
> > lightweight instrumentation of ovsdb-server, ovn-controller, and
> > ovn-northd.
> > While I'm familiar with the counters that are dumped during an
excessive
> > poll
> > cycle, those don't entirely meet our needs, as I am looking for
something
> > that allows for the amount of clock time spent in each method as our
> > starting point.
> >
> > The reason for the "lightweight" adjective above is that we are looking
to
> > run the same code base in both CI/CD and production, and that means
> > attaching
> > a profiler to the code base is contra-indicated. My initial thought is
to
> > create a new general arg (--profile) that sets a boolean (for example
> > is_profiling), then define a macro like the following:
> >
> > #define INSTRUMENT(x) (if (is_profiling) { VLOG_DEBUG(x); })
> >
> > and then decorating methods with INSTRUMENT at its start and exit.
>
> Something like this might work (GCC only):
>
> struct instrumentation {
> const char *function;
> long long int start;
> };
>
> #define INSTRUMENTATION \
> struct instrumentation inst __attribute__((cleanup(log_inst))) =
\
> { __func__, time_msec(); }
>
> void
> log_inst(const struct instrumentation *inst)
> {
> VLOG_DBG("%s: %d ms", inst->function, time_msec() - inst->start);
> }
>
> and then you'd only need one line for a whole function. I haven't tried
> it though.
If that works, it's rather clever - I was just thinking of dropping widow
marks in the log and letting the post-processing handle the calculation
>
> There's a PERF macro with a different design in lib/perf-counter.h.
>
Yes, I've looked at that and I don't think it quite does what I want
(I could be wrong though)
However, both of the above are currently optional things that *could*
be added by hand. Because of our CI/CD requirements, we'll need to feed
it with fully decorated files. Maintaining a local branch manually
in this scenario is not something I'd ask anybody to do, so the next
question is:
What are committers' feelings about merging completely decorated
files into the tree (before patches start being proposed)?
Ryan
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss
