[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20251025105944.1a04e518@batman.local.home>
Date: Sat, 25 Oct 2025 10:59:44 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Alex Markuze <amarkuze@...hat.com>
Cc: ceph-devel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, Liam.Howlett@...cle.com, akpm@...ux-foundation.org,
bsegall@...gle.com, david@...hat.com, dietmar.eggemann@....com,
idryomov@...il.com, mingo@...hat.com, juri.lelli@...hat.com,
kees@...nel.org, lorenzo.stoakes@...cle.com, mgorman@...e.de,
mhocko@...e.com, rppt@...nel.org, peterz@...radead.org, surenb@...gle.com,
vschneid@...hat.com, vincent.guittot@...aro.org, vbabka@...e.cz,
xiubli@...hat.com, Slava.Dubeyko@....com
Subject: Re: [RFC PATCH 0/5] BLOG: per-task logging contexts with Ceph
consumer
On Sat, 25 Oct 2025 13:50:39 +0300
Alex Markuze <amarkuze@...hat.com> wrote:
> First of all, Ftrace is for debugging and development; you won't see
> components or kernel modules run in production with ftrace enabled.
> The main motivation is to have verbose logging that is usable for
> production systems.
That is totally untrue. Several production environments use ftrace. We
have it enabled and used in Chromebooks and in Android. Google servers
also have it enabled.
> The second improvement is that the logs have a struct task hook which
> facilitates better logging association between the kernel log and the
> user process.
> It's especially handy when debugging FS systems.
So this is for use with debugging too?
>
> Specifically we had several bugs reported from the field that we could
> not make progress on without additional logs.
This still doesn't answer my question about not using ftrace. Heck,
when I worked for Red Hat, we used ftrace to debug production
environments. Did that change?
-- Steve
Powered by blists - more mailing lists