linux-kernel - Re: [RFC PATCH 0/4] perf: Custom contexts

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: <1300285912.2203.1580.camel@twins>
Date:	Wed, 16 Mar 2011 15:31:52 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Paul Mackerras <paulus@...ba.org>,
	Stephane Eranian <eranian@...gle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Hitoshi Mitake <mitake@....info.waseda.ac.jp>
Subject: Re: [RFC PATCH 0/4] perf: Custom contexts

On Wed, 2011-03-16 at 15:02 +0100, Frederic Weisbecker wrote:

> The possible usecase is so wide that I have a hard time to find a good
> example. Counting instructions in exceptions on some specific syscalls,
> counting instructions when some lock is taken on some irq handler, or
> whatever...

All of which can be done without the recursion, but ok.

But what you're saying is that you want to be able to build a full
expression tree of events.

Now the things I dislike about the whole thing is that its essentially a
filter, and we already have a filter thing, this adds a second totally
dis-joint filter capability.

Futhermore, you've split the start/stop things, as if they're somehow
different, when in fact they're pretty much the same thing, and you can
even think of more classes like a toggle event or whatever.

You've also split the start/stop events from the regular event lists
making the whole event management and inheritance stuff even more
complicated.

Furthermore, there is a definite possibility for weird behaviour in
there, in that if you're trying to measure a similar event to the one
that is used to enable/disable it, it very much depends on the order of
the demux lists as to which is processed first.

The simply scheme I came up with is having these events be part of the
event_group and add only one field:

  pause_ops : 2

with:

enum perf_event_pause_ops {
  PERF_PAUSE_OP_NOP = 0,
  PERF_PAUSE_OP_INC,
  PERF_PAUSE_OP_DEC,
  PERF_PAUSE_OP_TOGGLE,
};

and have INC increment the parent pause field and clip at INT_MAX, DEC
decrement the pause field and clip at 0, and TOGGLE do ^1.

That however doesn't allow for these full expression trees, so we need
to come up with something else. It does however do away with the
ioctl()s, that redundant flag and the weird event separation.

It is still susceptible to the demux order.

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