From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: "Liang, Kan" <kan.liang@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>,
jolsa@redhat.com, peterz@infradead.org, mingo@redhat.com,
linux-kernel@vger.kernel.org, namhyung@kernel.org,
adrian.hunter@intel.com, mathieu.poirier@linaro.org,
ravi.bangoria@linux.ibm.com, alexey.budankov@linux.intel.com,
vitaly.slobodskoy@intel.com, pavel.gerasimov@intel.com,
mpe@ellerman.id.au, eranian@google.com, ak@linux.intel.com
Subject: Re: [PATCH V2 1/9] perf pmu: Add support for PMU capabilities
Date: Tue, 10 Mar 2020 14:30:09 -0300 [thread overview]
Message-ID: <20200310173009.GJ15931@kernel.org> (raw)
In-Reply-To: <fa4e32f0-1572-a9aa-e609-3cecaae7ef9e@linux.intel.com>
Em Tue, Mar 10, 2020 at 12:54:05PM -0400, Liang, Kan escreveu:
>
>
> On 3/10/2020 10:04 AM, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Mar 10, 2020 at 09:53:24AM -0400, Liang, Kan escreveu:
> > > On 3/10/2020 9:06 AM, Arnaldo Carvalho de Melo wrote:
> > > > Em Mon, Mar 09, 2020 at 10:46:31AM -0700, kan.liang@linux.intel.com escreveu:
> > > > > +static int perf_pmu__new_caps(struct list_head *list, char *name, char *value)
> > > > > +{
> > > > > + struct perf_pmu_caps *caps;
> > > > > +
> > > > > + caps = zalloc(sizeof(*caps));
> > > > > + if (!caps)
> > > > > + return -ENOMEM;
> >
> > > > So here you check if zalloc fails and returns a proper error
> >
> > > > > + caps->name = strdup(name);
> > > > > + caps->value = strndup(value, strlen(value) - 1);
> >
> > > > But then you don't check strdup()?
> > > Right, I should check strdup(), otherwise the capability information may be
> > > incomplete. I will fix it in V3.
> >
> > Thanks, overall just consider making the patches smaller if possible,
> > with prep patches paving the way for more complex changes so that
> > reviewing becomes easier, for instance:
> >
> > perf machine: Refine the function for LBR call stack reconstruction
> >
> > Seems to do too many things at once. It was unfortunate, for instance,
> > that the pre-existing code had that
> >
> > resolve_lbr_callchain_sample()
> > {
> > /* LBR only affects the user callchain */
> > if (i != chain_nr) {
> > body of the function, long
> > ....
> > return err;
> > }
> >
> > return 0;
> > }
> >
> > One of the things you did in this patch was to the more sensible:
> >
> > /* LBR only affects the user callchain */
> > if (i == chain_nr)
> > return 0;
> >
> > body of the function
> > ...
> > return err;
> >
> > So if you had a prep patch at this point just removing that silly
> > indent, then we would see that that is just removing the indent, the
> > next patch wouldn't have that check for user callchains, would be
> > smaller, I think that would help reduce the patch sizes.
> > Then if you just moved to a separate function the (callchain_param.order
> > == ORDER_CALLEE) part, the patch would again be smaller, etc.
> > This helps reviewing and usually helps us later, with bisection, when
> > some bug is introduced,
> Sure, I will go through all patches and see what I can do to reduce the size
> of patches in V3.
Thanks a lot for considering my suggestions!
- Arnaldo
next prev parent reply other threads:[~2020-03-10 17:30 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 17:46 [PATCH V2 0/9] Stitch LBR call stack (Perf Tools) kan.liang
2020-03-09 17:46 ` [PATCH V2 1/9] perf pmu: Add support for PMU capabilities kan.liang
2020-03-10 13:06 ` Arnaldo Carvalho de Melo
2020-03-10 13:53 ` Liang, Kan
2020-03-10 14:04 ` Arnaldo Carvalho de Melo
2020-03-10 16:54 ` Liang, Kan
2020-03-10 17:30 ` Arnaldo Carvalho de Melo [this message]
2020-03-09 17:46 ` [PATCH V2 2/9] perf header: Support CPU " kan.liang
2020-03-09 17:46 ` [PATCH V2 3/9] perf machine: Refine the function for LBR call stack reconstruction kan.liang
2020-03-09 17:46 ` [PATCH V2 4/9] perf tools: Stitch LBR call stack kan.liang
2020-03-09 17:46 ` [PATCH V2 5/9] perf report: Add option to enable the LBR stitching approach kan.liang
2020-03-09 17:46 ` [PATCH V2 6/9] perf script: " kan.liang
2020-03-09 17:46 ` [PATCH V2 7/9] perf top: " kan.liang
2020-03-09 17:46 ` [PATCH V2 8/9] perf c2c: " kan.liang
2020-03-09 17:46 ` [PATCH V2 9/9] perf hist: Add fast path for duplicate entries check approach kan.liang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200310173009.GJ15931@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=adrian.hunter@intel.com \
--cc=ak@linux.intel.com \
--cc=alexey.budankov@linux.intel.com \
--cc=eranian@google.com \
--cc=jolsa@redhat.com \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=pavel.gerasimov@intel.com \
--cc=peterz@infradead.org \
--cc=ravi.bangoria@linux.ibm.com \
--cc=vitaly.slobodskoy@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.