Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 8 Dec 2022 07:15:49 -0500
From:   Petar Gligoric <petar.gligor@gmail.com>
To:     Namhyung Kim <namhyung@kernel.org>
Cc:     linux-kernel@vger.kernel.org,
        Petar Gligoric <petar.gligoric@rohde-schwarz.com>,
        Arnaldo Carvalho de Melo <acme@redhat.com>,
        Andi Kleen <ak@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>,
        Ian Rogers <irogers@google.com>,
        Hagen Paul Pfeifer <hagen@jauu.net>
Subject: Re: [PATCH v2 0/3] perf: introduce perf based task analyzer
Message-ID: <Y5HVdS3mlDruNyrl@debian>
References: <20221206154406.41941-1-petar.gligor@gmail.com>
 <CAM9d7cizPC3p0-Z1oYsDPofwNfZHyKYiJR5JXEcS31Q=mgzcLg@mail.gmail.com>
 <Y4/AfA2OYtlTkKwo@debian>
 <CAM9d7chLZVDg_-tnUh_qFYzchnpis-e7HYNDVM_OPjj_QXMeKQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAM9d7chLZVDg_-tnUh_qFYzchnpis-e7HYNDVM_OPjj_QXMeKQ@mail.gmail.com>
Precedence: bulk

> > Thanks for the input! For this patchset we explicitly decided against
> > extending "perf sched timehist" - after some pros and cons. Mainly we
> > didn't want to break existing programs (which might parse the output of
> > perf sched) and also the goal of the task-analyzer is a bit different.
> > E.g what will follow as a follow-up patch, is to show IRQs visually
> > pleasing intermixed with tasks to show potential sources of task
> > latency. This will be offered as an option for the task-analyzer, but
> > would be too much functionality for "perf sched timehist". This was the
> > main reason why we decided against the extension.
> 
> Then you might want to add a new sub-command under perf sched.
> But I guess we can just add a new option for the different output
> format in the perf sched timehist.
> 
> Anyway, "perf script" is a generic tool not targeting specific events.
> This functionality requires sched_switch (and more?) then we need
> the record part to make sure the data has the events.  That's why
> it's natural to have it in perf sched IMHO.
> 
> Thanks,
> Namhyung

We assumed that python scripts should not only be used as a "generic tool".
There are a number of tools like flamegraph, netdev-times, dropmonitor and
other scripts that analyze and look at *very specific* events. The question is
rather, why should this be implemented in C? When using Python - with batteries
included - less code has to be written for the identical result, and it is less
error-prone than C (less technical debt). We have measured the performance,
even for very large perf.data files, and again we see no problems.

But maybe this should be clarified in principle! What do you say Arnaldo, Ian,
...?

Petar