[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/30] Code tagging framework and applications
- To: Kent Overstreet <kent.overstreet@xxxxxxxxx>
- From: Steven Rostedt <rostedt@xxxxxxxxxxx>
- Date: Mon, 5 Sep 2022 18:16:50 -0400
- Cc: Suren Baghdasaryan <surenb@xxxxxxxxxx>, Michal Hocko <mhocko@xxxxxxxx>, Mel Gorman <mgorman@xxxxxxx>, Peter Zijlstra <peterz@xxxxxxxxxxxxx>, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>, Vlastimil Babka <vbabka@xxxxxxx>, Johannes Weiner <hannes@xxxxxxxxxxx>, Roman Gushchin <roman.gushchin@xxxxxxxxx>, Davidlohr Bueso <dave@xxxxxxxxxxxx>, Matthew Wilcox <willy@xxxxxxxxxxxxx>, "Liam R. Howlett" <liam.howlett@xxxxxxxxxx>, David Vernet <void@xxxxxxxxxxxxx>, Juri Lelli <juri.lelli@xxxxxxxxxx>, Laurent Dufour <ldufour@xxxxxxxxxxxxx>, Peter Xu <peterx@xxxxxxxxxx>, David Hildenbrand <david@xxxxxxxxxx>, Jens Axboe <axboe@xxxxxxxxx>, mcgrof@xxxxxxxxxx, masahiroy@xxxxxxxxxx, nathan@xxxxxxxxxx, changbin.du@xxxxxxxxx, ytcoode@xxxxxxxxx, Vincent Guittot <vincent.guittot@xxxxxxxxxx>, Dietmar Eggemann <dietmar.eggemann@xxxxxxx>, Benjamin Segall <bsegall@xxxxxxxxxx>, Daniel Bristot de Oliveira <bristot@xxxxxxxxxx>, Valentin Schneider <vschneid@xxxxxxxxxx>, Christopher Lameter <cl@xxxxxxxxx>, Pekka Enberg <penberg@xxxxxxxxxx>, Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>, 42.hyeyoo@xxxxxxxxx, Alexander Potapenko <glider@xxxxxxxxxx>, Marco Elver <elver@xxxxxxxxxx>, Dmitry Vyukov <dvyukov@xxxxxxxxxx>, Shakeel Butt <shakeelb@xxxxxxxxxx>, Muchun Song <songmuchun@xxxxxxxxxxxxx>, arnd@xxxxxxxx, jbaron@xxxxxxxxxx, David Rientjes <rientjes@xxxxxxxxxx>, Minchan Kim <minchan@xxxxxxxxxx>, Kalesh Singh <kaleshsingh@xxxxxxxxxx>, kernel-team <kernel-team@xxxxxxxxxxx>, linux-mm <linux-mm@xxxxxxxxx>, iommu@xxxxxxxxxxxxxxx, kasan-dev@xxxxxxxxxxxxxxxx, io-uring@xxxxxxxxxxxxxxx, linux-arch@xxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxx, linux-bcache@xxxxxxxxxxxxxxx, linux-modules@xxxxxxxxxxxxxxx, LKML <linux-kernel@xxxxxxxxxxxxxxx>
- Delivery-date: Mon, 05 Sep 2022 22:16:28 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On Mon, 5 Sep 2022 16:42:29 -0400
Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote:
> > Haven't tried that yet but will do. Thanks for the reference code!
>
> Is it really worth the effort of benchmarking tracing API overhead here?
>
> The main cost of a tracing based approach is going to to be the data structure
> for remembering outstanding allocations so that free events can be matched to
> the appropriate callsite. Regardless of whether it's done with BFP or by
> attaching to the tracepoints directly, that's going to be the main overhead.
The point I was making here is that you do not need your own hooking
mechanism. You can get the information directly by attaching to the
tracepoint.
> > static void my_callback(void *data, unsigned long call_site,
> > const void *ptr, struct kmem_cache *s,
> > size_t bytes_req, size_t bytes_alloc,
> > gfp_t gfp_flags)
> > {
> > struct my_data_struct *my_data = data;
> >
> > { do whatever }
> > }
The "do whatever" is anything you want to do.
Or is the data structure you create with this approach going to be too much
overhead? How hard is it for a hash or binary search lookup?
-- Steve
|