linux-kernel - Re: disabling group leader perf

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]

Message-ID: <1283868969.3594.99.camel@elnicho32>
Date:	Tue, 07 Sep 2010 09:16:09 -0500
From:	Tom Zanussi <tzanussi@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Peter Zijlstra <peterz@...radead.org>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Avi Kivity <avi@...hat.com>, linux-perf-users@...r.kernel.org,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: disabling group leader perf_event

On Tue, 2010-09-07 at 08:53 -0400, Steven Rostedt wrote:
> On Mon, 2010-09-06 at 11:42 -0500, Tom Zanussi wrote:
> > Hi,
> > 
> > On Mon, 2010-09-06 at 09:16 -0400, Steven Rostedt wrote:
> > > Sorry for top post, sending via my android phone. Today's a US holiday.
> > >  
> > > 
> > > We can filter before the work, if we expose the parameters. Currently we filter what goes into the buffer and there are several cases where we don't know the result before the work.
> > > 
> > > If we also expose the parameters of a TRACE_EVENT, then we can filter on them before the work.
> > 
> > I'm not sure exactly what you mean by exposing the parameters, but yeah,
> > in general it should be possible to filter on any field you can get the
> > address of, before you ever allocate space for the event or assign the
> > field to it.
> > 
> > In the cases where you don't know the result until you do the work, such
> > as for example this from kvm_age_page tracepoint:
> > 
> >         TP_fast_assign(
> >                 __entry->hva            = hva;
> >                 __entry->gfn            =
> >                   slot->base_gfn + ((hva - slot->userspace_addr) >>
> > PAGE_SHIFT);
> >                 __entry->referenced     = ref;
> >         ),
> > 
> > I guess you'd want the macro to assign the result to a temporary in
> > order to be able to participate in the filtering, or did you have
> > something else in mind?
> 
> Here we already did the work. We assigned everything, then might as well
> keep what we have. What I had in mind was:
> 
> TRACE_EVENT(kvm_age_page,
>         TP_PROTO(ulong hva, struct kvm_memory_slot *slot, int ref),
>         TP_ARGS(hva, slot, ref),
> 
> and be able to make a filter that says: slot->userspace_addr > X
> 
> Where we filter the parameters and not what is in the entry.
> Unfortunately, this would make TRACE_EVENT() even bigger since we would
> need to store what the parameter names are.
> 

Yeah, that would be nice to be able to do someday, with the full-fledged
interpreter being discussed; I was thinking for now of only the minimal
set of changes to the current filtering code needed to do the filtering
before the events hit the buffer, in which case I think for complex
expressions like this, you have to do the work of evaluating the full
expression before using the end result in a filter. 

Tom

> -- Steve
> 
> 
> 
> 


--
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/