[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/30] Code tagging framework and applications
- To: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
- From: Kent Overstreet <kent.overstreet@xxxxxxxxx>
- Date: Wed, 31 Aug 2022 04:42:30 -0400
- Cc: Suren Baghdasaryan <surenb@xxxxxxxxxx>, akpm@xxxxxxxxxxxxxxxxxxxx, mhocko@xxxxxxxx, vbabka@xxxxxxx, hannes@xxxxxxxxxxx, roman.gushchin@xxxxxxxxx, mgorman@xxxxxxx, dave@xxxxxxxxxxxx, willy@xxxxxxxxxxxxx, liam.howlett@xxxxxxxxxx, void@xxxxxxxxxxxxx, juri.lelli@xxxxxxxxxx, ldufour@xxxxxxxxxxxxx, peterx@xxxxxxxxxx, david@xxxxxxxxxx, axboe@xxxxxxxxx, mcgrof@xxxxxxxxxx, masahiroy@xxxxxxxxxx, nathan@xxxxxxxxxx, changbin.du@xxxxxxxxx, ytcoode@xxxxxxxxx, vincent.guittot@xxxxxxxxxx, dietmar.eggemann@xxxxxxx, rostedt@xxxxxxxxxxx, bsegall@xxxxxxxxxx, bristot@xxxxxxxxxx, vschneid@xxxxxxxxxx, cl@xxxxxxxxx, penberg@xxxxxxxxxx, iamjoonsoo.kim@xxxxxxx, 42.hyeyoo@xxxxxxxxx, glider@xxxxxxxxxx, elver@xxxxxxxxxx, dvyukov@xxxxxxxxxx, shakeelb@xxxxxxxxxx, songmuchun@xxxxxxxxxxxxx, arnd@xxxxxxxx, jbaron@xxxxxxxxxx, rientjes@xxxxxxxxxx, minchan@xxxxxxxxxx, kaleshsingh@xxxxxxxxxx, kernel-team@xxxxxxxxxxx, linux-mm@xxxxxxxxx, iommu@xxxxxxxxxxxxxxx, kasan-dev@xxxxxxxxxxxxxxxx, io-uring@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, linux-modules@xxxxxxxxxxxxxxx, linux-kernel@xxxxxxxxxxxxxxx
- Delivery-date: Wed, 31 Aug 2022 08:47:48 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Wed, Aug 31, 2022 at 09:38:27AM +0200, Peter Zijlstra wrote:
> On Tue, Aug 30, 2022 at 02:48:49PM -0700, Suren Baghdasaryan wrote:
> > ===========================
> > Code tagging framework
> > ===========================
> > Code tag is a structure identifying a specific location in the source code
> > which is generated at compile time and can be embedded in an application-
> > specific structure. Several applications of code tagging are included in
> > this RFC, such as memory allocation tracking, dynamic fault injection,
> > latency tracking and improved error code reporting.
> > Basically, it takes the old trick of "define a special elf section for
> > objects of a given type so that we can iterate over them at runtime" and
> > creates a proper library for it.
>
> I might be super dense this morning, but what!? I've skimmed through the
> set and I don't think I get it.
>
> What does this provide that ftrace/kprobes don't already allow?
You're kidding, right?
|
