Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Prasad Sodagudi <psodagud@codeaurora.org>, rostedt@goodmis.org,
        qais.yousef@arm.com, peterz@infradead.org, mingo@kernel.org,
        cai@lca.pw, tyhicks@canonical.com, arnd@arndb.de
Cc:     rameezmustafa@codeaurora.org, linux-kernel@vger.kernel.org,
        Prasad Sodagudi <psodagud@codeaurora.org>
Subject: Re: [PATCH 1/2] cpu/hotplug: Add cpuhp_latency trace event
In-Reply-To: <1600904266-102397-2-git-send-email-psodagud@codeaurora.org>
References: <1600904266-102397-1-git-send-email-psodagud@codeaurora.org> <1600904266-102397-2-git-send-email-psodagud@codeaurora.org>
Date:   Mon, 28 Sep 2020 16:58:09 +0200
Message-ID: <87tuvij6da.fsf@nanos.tec.linutronix.de>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

On Wed, Sep 23 2020 at 16:37, Prasad Sodagudi wrote:
> Add ftrace event trace_cpuhp_latency to track cpu
> hotplug latency. It helps to track the hotplug latency
> impact by firmware changes and kernel cpu hotplug callbacks.

Why?

And even if that makes sense, the implementation makes absolutely no
sense at all.

      trace_cpuhp_callback_enter();
      callback();
      trace_cpuhp_callback_exit();

No point in all this start time and conditional sched_clock() muck.

But then again, hotplug is slow by definition and nobody cares.

Thanks,

        tglx