linux-kernel - Re: perf: allow command to attach local data to thread/evsel structs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 7 Feb 2012 18:10:52 -0200
From:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
To:	David Ahern <dsahern@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Stephane Eranian <eranian@...gle.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: perf: allow command to attach local data to thread/evsel structs

Em Tue, Feb 07, 2012 at 11:11:48AM -0700, David Ahern escreveu:
> This is an API I have been using for some 'local' commands that process
> perf events. It allows the commands to attach data to events and threads
> and avoid local caching and lookups.

In the kernel proper we try to get away with this pattern using
container_of where possible.

Here tho the structures are created in library functions.

The symbol library has this symbol_conf.priv_size + symbol__priv() to do
what you want while avoiding two allocs + one pointer in a core
structure.

I think we either use {thread_conf,evsel_conf} for global configuration
options for these two core data structures or we just provide some
optional, per perf_tool allocator.

Yeah, that sounds extreme, but hey, this is a profiler, we ought to eat
our own dog food, right?

- Arnaldo

P.S.: Are your tools too specific or are they upstreamable?
 
> 
> diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> index 326b8e4..866de40 100644
> --- a/tools/perf/util/evsel.h
> +++ b/tools/perf/util/evsel.h
> @@ -66,6 +66,12 @@ struct perf_evsel {
>         void        *data;
>     } handler;
>     bool            supported;
> +
> +   /*
> +    * can be used by commands that process samples
> +    * for storing local, event-based data
> +    */
> +   void *private;
>  };
> 
>  struct cpu_map;
> diff --git a/tools/perf/util/thread.h b/tools/perf/util/thread.h
> index 70c2c13..9f62859 100644
> --- a/tools/perf/util/thread.h
> +++ b/tools/perf/util/thread.h
> @@ -16,6 +16,12 @@ struct thread {
>     bool            comm_set;
>     char            *comm;
>     int         comm_len;
> +
> +    /*
> +    * can be used by commands that process samples
> +    * for storing local, thread-based data
> +    */
> +   void *private;
>  };
> 
>  struct machine;
> 
> One wrinkle is that for the thread-based one the thread__delete(),
> thread__fork() and thread__set_comm() functions would free the
> allocations if set -- or a handler is needed to free private structs to
> handle layered mallocs.
> 
> Any objections to pushing this kind of open-ended API into perf?
> 
> David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/