[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZgXJH9XQNqda7fpz@slm.duckdns.org>
Date: Thu, 28 Mar 2024 09:46:39 -1000
From: Tejun Heo <tj@...nel.org>
To: Kent Overstreet <kent.overstreet@...ux.dev>
Cc: Kemeng Shi <shikemeng@...weicloud.com>, akpm@...ux-foundation.org,
willy@...radead.org, jack@...e.cz, bfoster@...hat.com,
dsterba@...e.com, mjguzik@...il.com, dhowells@...hat.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH v2 0/6] Improve visibility of writeback
Hello,
On Thu, Mar 28, 2024 at 03:40:02PM -0400, Kent Overstreet wrote:
> Collecting latency numbers at various key places is _enormously_ useful.
> The hard part is deciding where it's useful to collect; that requires
> intimate knowledge of the code. Once you're defining those collection
> poitns statically, doing it with BPF is just another useless layer of
> indirection.
Given how much flexibility helps with debugging, claiming it useless is a
stretch.
> The time stats stuff I wrote is _really_ cheap, and you really want this
> stuff always on so that you've actually got the data you need when
> you're bughunting.
For some stats and some use cases, always being available is useful and
building fixed infra for them makes sense. For other stats and other use
cases, flexibility is pretty useful too (e.g. what if you want percentile
distribution which is filtered by some criteria?). They aren't mutually
exclusive and I'm not sure bdi wb instrumentation is on top of enough
people's minds.
As for overhead, BPF instrumentation can be _really_ cheap too. We often run
these programs per packet.
Thanks.
--
tejun
Powered by blists - more mailing lists