Polish the ds.h interface and add support for PEBS.
Ds.c is meant to be the resource allocator for per-thread and per-cpu

BTS and PEBS recording.

It is used by ptrace/utrace to provide execution tracing of debugged tasks.

It will be used by profilers (e.g. perfmon2).

It may be used by kernel debuggers to provide a kernel execution trace.
Changes in detail:

- guard DS and ptrace by CONFIG macros

- separate DS and BTS more clearly

- simplify field accesses

- add functions to manage PEBS buffers

- add simple protection/allocation mechanism

- added support for Atom
Opens:

- buffer overflow handling

  Currently, only circular buffers are supported. This is all we need

  for debugging. Profilers would want an overflow notification.

  This is planned to be added when perfmon2 is made to use the ds.h

  interface.

- utrace intermediate layer
Signed-off-by: Markus Metzger <markus.t.metzger@intel.com>

---
Index: gits/include/asm-x86/ds.h

===================================================================

--- gits.orig/include/asm-x86/ds.h	2008-04-08 08:46:52.%N +0200

+++ gits/include/asm-x86/ds.h	2008-04-08 09:14:36.%N +0200

@@ -2,71 +2,237 @@

  * Debug Store (DS) support

  *

  * This provides a low-level interface to the hardware's Debug Store

- * feature that is used for last branch recording (LBR) and

+ * feature that is used for branch trace store (BTS) and

  * precise-event based sampling (PEBS).

  *

- * Different architectures use a different DS layout/pointer size.

- * The below functions therefore work on a void*.

+ * It manages:

+ * - per-thread and per-cpu allocation of BTS and PEBS

+ * - buffer memory allocation (optional)

+ * - buffer overflow handling

+ * - buffer access

+ *

+ * It assumes:

+ * - get_task_struct on all parameter tasks

+ * - current is allowed to trace parameter tasks

  *

  *

- * Since there is no user for PEBS, yet, only LBR (or branch

- * trace store, BTS) is supported.

- *

- *

- * Copyright (C) 2007 Intel Corporation.

- *...
[ message continues ]

On Tue, 8 Apr 2008 11:01:58 +0200
Should we skip the RLIMIT_MEMLOCK check if capable(CAP_IPC_LOCK)?
It's a fairly large patch.

--

btw., it's already in x86/testing (has been since last week) and hence

it's in linux-next as well.
it's still under the "needs some sort of positive noises from Roland"

tag though ...
	Ingo

--

Ingo,
Does this include the PEBS support?

--

The original version was much smaller -- a lot of the increase came out of

review feedback for "more infrastructure" etc. I don't think you can blame

Markus for that.
-Andi

--

That is true even though I see in mlock() that both are actually used.

I don't check against capabilities in perfmon, but I check RLIMIT_MEMLOCK

for the sampling buffer.
I see the capset()/capget() syscalls, however, I am still not clear as to how a

sysadmin could set up the capabilities for users via PAM or other

I believe the patch could potentially be broken into multiple pieces:

ds/bts, pebs, ptrace.

--