Welcome to Soft32 Linux Forums!
FAQFAQ    SearchSearch      ProfileProfile    Private MessagesPrivate Messages   Log inLog in

[GIT PULL v2] hw-breakpoints: Rewrite on top of perf events

 
   Soft32 Home -> Linux -> Kernel RSS
Next:  [GIT PULL] core kernel fixes  
Author Message
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 1) Posted: Sat Oct 24, 2009 1:21 pm
Post subject: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events
Archived from groups: linux>kernel (more info?)

Hi all,

This is the v2 of the hw-breakpoints API rewrite on top of perf events.
You can find the previous version here:
http://lwn.net/Articles/351922/

Changes in v2:

- Follow the perf "event " rename
- The ptrace regression have been fixed (ptrace breakpoint perf events
weren't released when a task ended)
- Drop the struct hw_breakpoint and store generic fields in
perf_event_attr.
- Separate core and arch specific headers, drop
asm-generic/hw_breakpoint.h and create linux/hw_breakpoint.h
- Use new generic len/type for breakpoint
- Handle off case: when breakpoints api is not supported by an arch
- Use proper in-kernel perf api provided by Arjan.

There are still a lot of things that need to be cleaned, simplified,
improved (ptrace side, the bp api, etc....) I guess these things can
be done incrementally if you agree.

I've also tried to get an arch-independent api. Generic fields for
breakpoints are stored in perf_event_attr structure (type, len, addr).
This needs to be discussed and improved before it becomes a perf
userspace ABI. We need to find a generic enough structure to host
the breakpoints parameters, something that can better fit to most arch
(handling breakpoint ranges in powerpc, etc...).

Thanks.

---

The following patchset are available in the git repository at:

git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git
perfevents/hw-breakpoint

Arjan van de Ven (1):
perf/core: Provide a kernel-internal interface to get to performance counters

Frederic Weisbecker (3):
perf/core: Add a callback to perf events
hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events
hw-breakpoints: Arbitrate access to pmu following registers constraints

Li Zefan (1):
ksym_tracer: Remove KSYM_SELFTEST_ENTRY

Paul Mundt (1):
x86/hw-breakpoints: Actually flush thread breakpoints in flush_thread().

arch/Kconfig | 3 +
arch/x86/include/asm/debugreg.h | 7 -
arch/x86/include/asm/hw_breakpoint.h | 58 +++--
arch/x86/include/asm/processor.h | 12 +-
arch/x86/kernel/hw_breakpoint.c | 376 ++++++++++++++--------
arch/x86/kernel/process.c | 9 +-
arch/x86/kernel/process_32.c | 26 +--
arch/x86/kernel/process_64.c | 26 +--
arch/x86/kernel/ptrace.c | 182 +++++++----
arch/x86/kernel/smpboot.c | 3 -
arch/x86/power/cpu.c | 6 -
include/asm-generic/hw_breakpoint.h | 139 --------
include/linux/hw_breakpoint.h | 131 ++++++++
include/linux/perf_event.h | 37 ++-
kernel/exit.c | 5 +
kernel/hw_breakpoint.c | 595 +++++++++++++++++++++-------------
kernel/perf_event.c | 137 ++++++++-
kernel/trace/trace.h | 1 -
kernel/trace/trace_entries.h | 6 +-
kernel/trace/trace_ksym.c | 126 ++++----
kernel/trace/trace_selftest.c | 2 +-
21 files changed, 1154 insertions(+), 733 deletions(-)
delete mode 100644 include/asm-generic/hw_breakpoint.h
create mode 100644 include/linux/hw_breakpoint.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 2) Posted: Sat Oct 24, 2009 1:21 pm
Post subject: [PATCH 5/6] hw-breakpoints: Arbitrate access to pmu following registers constraints [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

Allow or refuse to build a counter using the breakpoints pmu following
given constraints.

We keep track of the pmu users by using three per cpu variables:

- nr_cpu_bp_pinned stores the number of pinned cpu breakpoints counters
in the given cpu

- nr_bp_flexible stores the number of non-pinned breakpoints counters
in the given cpu.

- task_bp_pinned stores the number of pinned task breakpoints in a cpu

The latter is not a simple counter but gathers the number of tasks that
have n pinned breakpoints.
Considering HBP_NUM the number of available breakpoint address
registers:
task_bp_pinned[0] is the number of tasks having 1 breakpoint
task_bp_pinned[1] is the number of tasks having 2 breakpoints
[...]
task_bp_pinned[HBP_NUM - 1] is the number of tasks having the
maximum number of registers (HBP_NUM).

When a breakpoint counter is created and wants an access to the pmu,
we evaluate the following constraints:

== Non-pinned counter ==

- If attached to a single cpu, check:

(per_cpu(nr_bp_flexible, cpu) || (per_cpu(nr_cpu_bp_pinned, cpu)
+ max(per_cpu(task_bp_pinned, cpu)))) < HBP_NUM

-> If there are already non-pinned counters in this cpu, it
means there is already a free slot for them.
Otherwise, we check that the maximum number of per task
breakpoints (for this cpu) plus the number of per cpu
breakpoint (for this cpu) doesn't cover every registers.

- If attached to every cpus, check:

(per_cpu(nr_bp_flexible, *) || (max(per_cpu(nr_cpu_bp_pinned, *))
+ max(per_cpu(task_bp_pinned, *)))) < HBP_NUM

-> This is roughly the same, except we check the number of per
cpu bp for every cpu and we keep the max one. Same for the
per tasks breakpoints.

== Pinned counter ==

- If attached to a single cpu, check:

((per_cpu(nr_bp_flexible, cpu) > 1)
+ per_cpu(nr_cpu_bp_pinned, cpu)
+ max(per_cpu(task_bp_pinned, cpu))) < HBP_NUM

-> Same checks as before. But now the nr_bp_flexible, if any,
must keep one register at least (or flexible breakpoints will
never be be fed).

- If attached to every cpus, check:

((per_cpu(nr_bp_flexible, *) > 1)
+ max(per_cpu(nr_cpu_bp_pinned, *))
+ max(per_cpu(task_bp_pinned, *))) < HBP_NUM

Changes in v2:

- Counter -> event rename

Signed-off-by: Frederic Weisbecker <fweisbec DeleteThis @gmail.com>
Cc: Prasad <prasad DeleteThis @linux.vnet.ibm.com>
Cc: Alan Stern <stern DeleteThis @rowland.harvard.edu>
Cc: Peter Zijlstra <peterz DeleteThis @infradead.org>
Cc: Arnaldo Carvalho de Melo <acme DeleteThis @redhat.com>
Cc: Steven Rostedt <rostedt DeleteThis @goodmis.org>
Cc: Ingo Molnar <mingo DeleteThis @elte.hu>
Cc: Jan Kiszka <jan.kiszka DeleteThis @web.de>
Cc: Jiri Slaby <jirislaby DeleteThis @gmail.com>
Cc: Li Zefan <lizf DeleteThis @cn.fujitsu.com>
Cc: Avi Kivity <avi DeleteThis @redhat.com>
Cc: Paul Mackerras <paulus DeleteThis @samba.org>
Cc: Mike Galbraith <efault DeleteThis @gmx.de>
Cc: Masami Hiramatsu <mhiramat DeleteThis @redhat.com>
Cc: Paul Mundt <lethal DeleteThis @linux-sh.org>
---
kernel/hw_breakpoint.c | 237 ++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 231 insertions(+), 6 deletions(-)

diff --git a/kernel/hw_breakpoint.c b/kernel/hw_breakpoint.c
index 08f6d01..60ff182 100644
--- a/kernel/hw_breakpoint.c
+++ b/kernel/hw_breakpoint.c
@@ -16,6 +16,8 @@
* Copyright (C) 2007 Alan Stern
* Copyright (C) IBM Corporation, 2009
* Copyright (C) 2009, Frederic Weisbecker <fweisbec DeleteThis @gmail.com>
+ *
+ * Thanks to Ingo Molnar for his many suggestions.
*/

/*
@@ -44,24 +46,247 @@
#include <asm/debugreg.h>
#endif

-static atomic_t bp_slot;
+/*
+ * Constraints data
+ */
+
+/* Number of pinned cpu breakpoints in a cpu */
+static DEFINE_PER_CPU(unsigned int, nr_cpu_bp_pinned);

-int reserve_bp_slot(struct perf_event *bp)
+/* Number of pinned task breakpoints in a cpu */
+static DEFINE_PER_CPU(unsigned int, task_bp_pinned[HBP_NUM]);
+
+/* Number of non-pinned cpu/task breakpoints in a cpu */
+static DEFINE_PER_CPU(unsigned int, nr_bp_flexible);
+
+/* Gather the number of total pinned and un-pinned bp in a cpuset */
+struct bp_busy_slots {
+ unsigned int pinned;
+ unsigned int flexible;
+};
+
+/* Serialize accesses to the above constraints */
+static DEFINE_MUTEX(nr_bp_mutex);
+
+/*
+ * Report the maximum number of pinned breakpoints a task
+ * have in this cpu
+ */
+static unsigned int max_task_bp_pinned(int cpu)
{
- if (atomic_inc_return(&bp_slot) == HBP_NUM) {
- atomic_dec(&bp_slot);
+ int i;
+ unsigned int *tsk_pinned = per_cpu(task_bp_pinned, cpu);

- return -ENOSPC;
+ for (i = HBP_NUM -1; i >= 0; i--) {
+ if (tsk_pinned[i] > 0)
+ return i + 1;
}

return 0;
}

+/*
+ * Report the number of pinned/un-pinned breakpoints we have in
+ * a given cpu (cpu > -1) or in all of them (cpu = -1).
+ */
+static void fetch_bp_busy_slots(struct bp_busy_slots *slots, int cpu)
+{
+ if (cpu >= 0) {
+ slots->pinned = per_cpu(nr_cpu_bp_pinned, cpu);
+ slots->pinned += max_task_bp_pinned(cpu);
+ slots->flexible = per_cpu(nr_bp_flexible, cpu);
+
+ return;
+ }
+
+ for_each_online_cpu(cpu) {
+ unsigned int nr;
+
+ nr = per_cpu(nr_cpu_bp_pinned, cpu);
+ nr += max_task_bp_pinned(cpu);
+
+ if (nr > slots->pinned)
+ slots->pinned = nr;
+
+ nr = per_cpu(nr_bp_flexible, cpu);
+
+ if (nr > slots->flexible)
+ slots->flexible = nr;
+ }
+}
+
+/*
+ * Add a pinned breakpoint for the given task in our constraint table
+ */
+static void toggle_bp_task_slot(struct task_struct *tsk, int cpu, bool enable)
+{
+ int count = 0;
+ struct perf_event *bp;
+ struct perf_event_context *ctx = tsk->perf_event_ctxp;
+ unsigned int *task_bp_pinned;
+ struct list_head *list;
+ unsigned long flags;
+
+ if (WARN_ONCE(!ctx, "No perf context for this task"))
+ return;
+
+ list = &ctx->event_list;
+
+ spin_lock_irqsave(&ctx->lock, flags);
+
+ /*
+ * The current breakpoint counter is not included in the list
+ * at the open() callback time
+ */
+ list_for_each_entry(bp, list, event_entry) {
+ if (bp->attr.type == PERF_TYPE_BREAKPOINT)
+ count++;
+ }
+
+ spin_unlock_irqrestore(&ctx->lock, flags);
+
+ if (WARN_ONCE(count < 0, "No breakpoint counter found in the counter list"))
+ return;
+
+ task_bp_pinned = per_cpu(task_bp_pinned, cpu);
+ if (enable) {
+ task_bp_pinned[count]++;
+ if (count > 0)
+ task_bp_pinned[count-1]--;
+ } else {
+ task_bp_pinned[count]--;
+ if (count > 0)
+ task_bp_pinned[count-1]++;
+ }
+}
+
+/*
+ * Add/remove the given breakpoint in our constraint table
+ */
+static void toggle_bp_slot(struct perf_event *bp, bool enable)
+{
+ int cpu = bp->cpu;
+ unsigned int *nr;
+ struct task_struct *tsk = bp->ctx->task;
+
+ /* Flexible */
+ if (!bp->attr.pinned) {
+ if (cpu >= 0) {
+ nr = &per_cpu(nr_bp_flexible, cpu);
+ goto toggle;
+ }
+
+ for_each_online_cpu(cpu) {
+ nr = &per_cpu(nr_bp_flexible, cpu);
+ goto toggle;
+ }
+ }
+ /* Pinned counter task profiling */
+ if (tsk) {
+ if (cpu >= 0) {
+ toggle_bp_task_slot(tsk, cpu, enable);
+ return;
+ }
+
+ for_each_online_cpu(cpu)
+ toggle_bp_task_slot(tsk, cpu, enable);
+ return;
+ }
+
+ /* Pinned counter cpu profiling */
+ nr = &per_cpu(nr_cpu_bp_pinned, bp->cpu);
+
+toggle:
+ *nr = enable ? *nr + 1 : *nr - 1;
+}
+
+/*
+ * Contraints to check before allowing this new breakpoint counter:
+ *
+ * == Non-pinned counter ==
+ *
+ * - If attached to a single cpu, check:
+ *
+ * (per_cpu(nr_bp_flexible, cpu) || (per_cpu(nr_cpu_bp_pinned, cpu)
+ * + max(per_cpu(task_bp_pinned, cpu)))) < HBP_NUM
+ *
+ * -> If there are already non-pinned counters in this cpu, it means
+ * there is already a free slot for them.
+ * Otherwise, we check that the maximum number of per task
+ * breakpoints (for this cpu) plus the number of per cpu breakpoint
+ * (for this cpu) doesn't cover every registers.
+ *
+ * - If attached to every cpus, check:
+ *
+ * (per_cpu(nr_bp_flexible, *) || (max(per_cpu(nr_cpu_bp_pinned, *))
+ * + max(per_cpu(task_bp_pinned, *)))) < HBP_NUM
+ *
+ * -> This is roughly the same, except we check the number of per cpu
+ * bp for every cpu and we keep the max one. Same for the per tasks
+ * breakpoints.
+ *
+ *
+ * == Pinned counter ==
+ *
+ * - If attached to a single cpu, check:
+ *
+ * ((per_cpu(nr_bp_flexible, cpu) > 1) + per_cpu(nr_cpu_bp_pinned, cpu)
+ * + max(per_cpu(task_bp_pinned, cpu))) < HBP_NUM
+ *
+ * -> Same checks as before. But now the nr_bp_flexible, if any, must keep
+ * one register at least (or they will never be fed).
+ *
+ * - If attached to every cpus, check:
+ *
+ * ((per_cpu(nr_bp_flexible, *) > 1) + max(per_cpu(nr_cpu_bp_pinned, *))
+ * + max(per_cpu(task_bp_pinned, *))) < HBP_NUM
+ */
+int reserve_bp_slot(struct perf_event *bp)
+{
+ struct bp_busy_slots slots = {0};
+ int ret = 0;
+
+ mutex_lock(&nr_bp_mutex);
+
+ fetch_bp_busy_slots(&slots, bp->cpu);
+
+ if (!bp->attr.pinned) {
+ /*
+ * If there are already flexible counters here,
+ * there is at least one slot reserved for all
+ * of them. Just join the party.
+ *
+ * Otherwise, check there is at least one free slot
+ */
+ if (!slots.flexible && slots.pinned == HBP_NUM) {
+ ret = -ENOSPC;
+ goto end;
+ }
+
+ /* Flexible counters need to keep at least one slot */
+ } else if (slots.pinned + (!!slots.flexible) == HBP_NUM) {
+ ret = -ENOSPC;
+ goto end;
+ }
+
+ toggle_bp_slot(bp, true);
+
+end:
+ mutex_unlock(&nr_bp_mutex);
+
+ return ret;
+}
+
void release_bp_slot(struct perf_event *bp)
{
- atomic_dec(&bp_slot);
+ mutex_lock(&nr_bp_mutex);
+
+ toggle_bp_slot(bp, false);
+
+ mutex_unlock(&nr_bp_mutex);
}

+
int __register_perf_hw_breakpoint(struct perf_event *bp)
{
int ret;
--
1.6.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 3) Posted: Sat Oct 24, 2009 1:21 pm
Post subject: [PATCH 6/6] ksym_tracer: Remove KSYM_SELFTEST_ENTRY [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

From: Li Zefan <lizf.TakeThisOut@cn.fujitsu.com>

The macro used to be used in both trace_selftest.c and
trace_ksym.c, but no longer, so remove it from header file.

Signed-off-by: Li Zefan <lizf.TakeThisOut@cn.fujitsu.com>
Cc: Prasad <prasad.TakeThisOut@linux.vnet.ibm.com>
Signed-off-by: Frederic Weisbecker <fweisbec.TakeThisOut@gmail.com>
---
kernel/trace/trace.h | 1 -
kernel/trace/trace_selftest.c | 2 +-
2 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 91c3d0e..85ba332 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -370,7 +370,6 @@ int register_tracer(struct tracer *type);
void unregister_tracer(struct tracer *type);
int is_tracing_stopped(void);

-#define KSYM_SELFTEST_ENTRY "ksym_selftest_dummy"
extern int process_new_ksym_entry(char *ksymname, int op, unsigned long addr);

extern unsigned long nsecs_to_usecs(unsigned long nsecs);
diff --git a/kernel/trace/trace_selftest.c b/kernel/trace/trace_selftest.c
index 7179c12..a006f00 100644
--- a/kernel/trace/trace_selftest.c
+++ b/kernel/trace/trace_selftest.c
@@ -828,7 +828,7 @@ trace_selftest_startup_ksym(struct tracer *trace, struct trace_array *tr)

ksym_selftest_dummy = 0;
/* Register the read-write tracing request */
- ret = process_new_ksym_entry(KSYM_SELFTEST_ENTRY, HW_BREAKPOINT_RW,
+ ret = process_new_ksym_entry("ksym_selftest_dummy", HW_BREAKPOINT_RW,
(unsigned long)(&ksym_selftest_dummy));

if (ret < 0) {
--
1.6.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 4) Posted: Sat Oct 24, 2009 1:21 pm
Post subject: [PATCH 3/6] perf/core: Add a callback to perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

A simple callback in a perf event can be used for multiple purposes.
For example it is useful for triggered based events like hardware
breakpoints that need a callback to dispatch a triggered breakpoint
event.

Signed-off-by: Frederic Weisbecker <fweisbec DeleteThis @gmail.com>
Cc: Peter Zijlstra <peterz DeleteThis @infradead.org>
Cc: "K.Prasad" <prasad DeleteThis @linux.vnet.ibm.com>
Cc: Alan Stern <stern DeleteThis @rowland.harvard.edu>
Cc: Arnaldo Carvalho de Melo <acme DeleteThis @redhat.com>
Cc: Steven Rostedt <rostedt DeleteThis @goodmis.org>
Cc: Ingo Molnar <mingo DeleteThis @elte.hu>
Cc: Paul Mackerras <paulus DeleteThis @samba.org>
Cc: Mike Galbraith <efault DeleteThis @gmx.de>
Cc: Paul Mundt <lethal DeleteThis @linux-sh.org>
---
include/linux/perf_event.h | 7 ++++++-
kernel/perf_event.c | 18 ++++++++++++++----
2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index fa151d4..8d54e6d 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -544,6 +544,8 @@ struct perf_pending_entry {
void (*func)(struct perf_pending_entry *);
};

+typedef void (*perf_callback_t)(struct perf_event *, void *);
+
/**
* struct perf_event - performance event kernel representation:
*/
@@ -639,6 +641,8 @@ struct perf_event {
struct event_filter *filter;
#endif

+ perf_callback_t callback;
+
#endif /* CONFIG_PERF_EVENTS */
};

@@ -748,7 +752,8 @@ extern int perf_event_release_kernel(struct perf_event *event);
extern struct perf_event *
perf_event_create_kernel_counter(struct perf_event_attr *attr,
int cpu,
- pid_t pid);
+ pid_t pid,
+ perf_callback_t callback);
extern u64 perf_event_read_value(struct perf_event *event);

struct perf_sample_data {
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 1fc69d8..34866d0 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -4293,6 +4293,7 @@ perf_event_alloc(struct perf_event_attr *attr,
struct perf_event_context *ctx,
struct perf_event *group_leader,
struct perf_event *parent_event,
+ perf_callback_t callback,
gfp_t gfpflags)
{
const struct pmu *pmu;
@@ -4335,6 +4336,15 @@ perf_event_alloc(struct perf_event_attr *attr,

event->state = PERF_EVENT_STATE_INACTIVE;

+ if (!callback) {
+ if (parent_event)
+ event->callback = parent_event->callback;
+ else
+ event->callback = NULL;
+ } else {
+ event->callback = callback;
+ }
+
if (attr->disabled)
event->state = PERF_EVENT_STATE_OFF;

@@ -4611,7 +4621,7 @@ SYSCALL_DEFINE5(perf_event_open,
}

event = perf_event_alloc(&attr, cpu, ctx, group_leader,
- NULL, GFP_KERNEL);
+ NULL, NULL, GFP_KERNEL);
err = PTR_ERR(event);
if (IS_ERR(event))
goto err_put_context;
@@ -4665,7 +4675,7 @@ err_put_context:
*/
struct perf_event *
perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
- pid_t pid)
+ pid_t pid, perf_callback_t callback)
{
struct perf_event *event;
struct perf_event_context *ctx;
@@ -4680,7 +4690,7 @@ perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
return NULL ;

event = perf_event_alloc(attr, cpu, ctx, NULL,
- NULL, GFP_KERNEL);
+ NULL, callback, GFP_KERNEL);
err = PTR_ERR(event);
if (IS_ERR(event))
goto err_put_context;
@@ -4733,7 +4743,7 @@ inherit_event(struct perf_event *parent_event,
child_event = perf_event_alloc(&parent_event->attr,
parent_event->cpu, child_ctx,
group_leader, parent_event,
- GFP_KERNEL);
+ NULL, GFP_KERNEL);
if (IS_ERR(child_event))
return child_event;
get_ctx(child_ctx);
--
1.6.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 5) Posted: Sat Oct 24, 2009 1:21 pm
Post subject: [PATCH 1/6] perf/core: Provide a kernel-internal interface to get to performance counters [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

From: Arjan van de Ven <arjan RemoveThis @infradead.org>

There are reasons for kernel code to ask for, and use, performance
counters.
For example, in CPU freq governors this tends to be a good idea, but
there are other examples possible as well of course.

This patch adds the needed bits to do enable this functionality; they
have been tested in an experimental cpufreq driver that I'm working on,
and the changes are all that I needed to access counters properly.

[fweisbec@gmail.com: added pid to perf_event_create_kernel_counter so
that we can profile a particular task too

TODO: Have a better error reporting, don't just return NULL in fail
case.]

Signed-off-by: Arjan van de Ven <arjan RemoveThis @linux.intel.com>
Acked-by: Peter Zijlstra <peterz RemoveThis @infradead.org>
Cc: "K.Prasad" <prasad RemoveThis @linux.vnet.ibm.com>
Cc: Alan Stern <stern RemoveThis @rowland.harvard.edu>
Cc: Arnaldo Carvalho de Melo <acme RemoveThis @redhat.com>
Cc: Steven Rostedt <rostedt RemoveThis @goodmis.org>
Cc: Ingo Molnar <mingo RemoveThis @elte.hu>
Cc: Jan Kiszka <jan.kiszka RemoveThis @siemens.com>
Cc: Jiri Slaby <jirislaby RemoveThis @gmail.com>
Cc: Li Zefan <lizf RemoveThis @cn.fujitsu.com>
Cc: Avi Kivity <avi RemoveThis @redhat.com>
Cc: Paul Mackerras <paulus RemoveThis @samba.org>
Cc: Mike Galbraith <efault RemoveThis @gmx.de>
Cc: Masami Hiramatsu <mhiramat RemoveThis @redhat.com>
Cc: Paul Mundt <lethal RemoveThis @linux-sh.org>
Cc: Jan Kiszka <jan.kiszka RemoveThis @web.de>
Cc: Avi Kivity <avi RemoveThis @redhat.com>
LKML-Reference: <20090925122556.2f8bd939 RemoveThis @infradead.org>
Signed-off-by: Frederic Weisbecker <fweisbec RemoveThis @gmail.com>
---
include/linux/perf_event.h | 6 ++++
kernel/perf_event.c | 72 +++++++++++++++++++++++++++++++++++++++++++-
2 files changed, 77 insertions(+), 1 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index df9d964..fa151d4 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -744,6 +744,12 @@ extern int hw_perf_group_sched_in(struct perf_event *group_leader,
struct perf_cpu_context *cpuctx,
struct perf_event_context *ctx, int cpu);
extern void perf_event_update_userpage(struct perf_event *event);
+extern int perf_event_release_kernel(struct perf_event *event);
+extern struct perf_event *
+perf_event_create_kernel_counter(struct perf_event_attr *attr,
+ int cpu,
+ pid_t pid);
+extern u64 perf_event_read_value(struct perf_event *event);

struct perf_sample_data {
u64 type;
diff --git a/kernel/perf_event.c b/kernel/perf_event.c
index 12b5ec3..1fc69d8 100644
--- a/kernel/perf_event.c
+++ b/kernel/perf_event.c
@@ -1725,6 +1725,26 @@ static int perf_release(struct inode *inode, struct file *file)
return 0;
}

+int perf_event_release_kernel(struct perf_event *event)
+{
+ struct perf_event_context *ctx = event->ctx;
+
+ WARN_ON_ONCE(ctx->parent_ctx);
+ mutex_lock(&ctx->mutex);
+ perf_event_remove_from_context(event);
+ mutex_unlock(&ctx->mutex);
+
+ mutex_lock(&event->owner->perf_event_mutex);
+ list_del_init(&event->owner_entry);
+ mutex_unlock(&event->owner->perf_event_mutex);
+ put_task_struct(event->owner);
+
+ free_event(event);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(perf_event_release_kernel);
+
static int perf_event_read_size(struct perf_event *event)
{
int entry = sizeof(u64); /* value */
@@ -1750,7 +1770,7 @@ static int perf_event_read_size(struct perf_event *event)
return size;
}

-static u64 perf_event_read_value(struct perf_event *event)
+u64 perf_event_read_value(struct perf_event *event)
{
struct perf_event *child;
u64 total = 0;
@@ -1761,6 +1781,7 @@ static u64 perf_event_read_value(struct perf_event *event)

return total;
}
+EXPORT_SYMBOL_GPL(perf_event_read_value);

static int perf_event_read_entry(struct perf_event *event,
u64 read_format, char __user *buf)
@@ -4639,6 +4660,55 @@ err_put_context:
}

/*
+ * perf_event_create_kernel_counter
+ * MUST be called from a kernel thread.
+ */
+struct perf_event *
+perf_event_create_kernel_counter(struct perf_event_attr *attr, int cpu,
+ pid_t pid)
+{
+ struct perf_event *event;
+ struct perf_event_context *ctx;
+ int err;
+
+ /*
+ * Get the target context (task or percpu):
+ */
+
+ ctx = find_get_context(pid, cpu);
+ if (IS_ERR(ctx))
+ return NULL ;
+
+ event = perf_event_alloc(attr, cpu, ctx, NULL,
+ NULL, GFP_KERNEL);
+ err = PTR_ERR(event);
+ if (IS_ERR(event))
+ goto err_put_context;
+
+ event->filp = NULL;
+ WARN_ON_ONCE(ctx->parent_ctx);
+ mutex_lock(&ctx->mutex);
+ perf_install_in_context(ctx, event, cpu);
+ ++ctx->generation;
+ mutex_unlock(&ctx->mutex);
+
+ event->owner = current;
+ get_task_struct(current);
+ mutex_lock(&current->perf_event_mutex);
+ list_add_tail(&event->owner_entry, &current->perf_event_list);
+ mutex_unlock(&current->perf_event_mutex);
+
+ return event;
+
+err_put_context:
+ if (err < 0)
+ put_ctx(ctx);
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(perf_event_create_kernel_counter);
+
+/*
* inherit a event from parent task to child task:
*/
static struct perf_event *
--
1.6.2.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 6) Posted: Sun Oct 25, 2009 7:20 pm
Post subject: Re: [PATCH 4/6] hw-breakpoints: Rewrite the hw-breakpoints layer on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

2009/10/24 Jan Kiszka <jan.kiszka.TakeThisOut@web.de>:
> Since commit 3d53c27d05, KVM uses current->thread.debugregs for
> restoring the host state in case the guest played with breakpoints. We
> need an equivalent interface to restore ptrace breakpoints and all
> others currently in use.
>
> Jan


Well, dr6 is still stored in the current thread.
dr7 has a per cpu variable containing its value.

So what remains is to have a per cpu variable for dr0-3
which is updated when perf schedules in/out a profiled context.
I can do that in a v3.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.TakeThisOut@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
K.Prasad

External


Since: Dec 04, 2008
Posts: 27



(Msg. 7) Posted: Mon Oct 26, 2009 5:20 pm
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Sat, Oct 24, 2009 at 04:16:52PM +0200, Frederic Weisbecker wrote:
> Hi all,
>
> This is the v2 of the hw-breakpoints API rewrite on top of perf events.
> You can find the previous version here:
> http://lwn.net/Articles/351922/
>
> Changes in v2:
>
> - Follow the perf "event " rename
> - The ptrace regression have been fixed (ptrace breakpoint perf events
> weren't released when a task ended)
> - Drop the struct hw_breakpoint and store generic fields in
> perf_event_attr.
> - Separate core and arch specific headers, drop
> asm-generic/hw_breakpoint.h and create linux/hw_breakpoint.h
> - Use new generic len/type for breakpoint
> - Handle off case: when breakpoints api is not supported by an arch
> - Use proper in-kernel perf api provided by Arjan.
>
> There are still a lot of things that need to be cleaned, simplified,
> improved (ptrace side, the bp api, etc....) I guess these things can
> be done incrementally if you agree.
>
> I've also tried to get an arch-independent api. Generic fields for
> breakpoints are stored in perf_event_attr structure (type, len, addr).
> This needs to be discussed and improved before it becomes a perf
> userspace ABI. We need to find a generic enough structure to host
> the breakpoints parameters, something that can better fit to most arch
> (handling breakpoint ranges in powerpc, etc...).
>

Outside the specific comments about the implementation here, I think
the patchset begets a larger question about hw-breakpoint layer's
integration with perf-events.

Upon being a witness to the proposed changes and after some exploration
of perf_events' functionality, I'm afraid that hw-breakpoint integration
with perf doesn't benefit the former as much as originally wished to be
(http://lkml.org/lkml/2009/8/26/149).

Some of the prevalent concerns (which have been raised in different
threads earlier) are:

- While kernel-space breakpoints need to reside on every processor
(irrespective of the process in user-space), perf-events' notion of a
counter is always linked to a process context (although there could be
workarounds by making it 'pinned', etc).

- HW Breakpoints register allocation mechanism is 'greedy', which in my
opinion is more suitable for allocating a finite and contended
resource such as debug register while that of perf-events can give
rise to roll-backs (with side-effects such as stray exceptions and
race conditions).

- Given that the notion of a per-process context for counters is
well-ingrained into the design of perf-events (even system-wide
counters are sometimes implemented through individual syscalls over
nr_cpus as in builtin-stat.c), it requires huge re-design and
user-space changes.

Trying to scoop out the hw-breakpoint layer off its book-keeping/register
allocation features only to replace with that of perf-events leads to a
poor retrofit. On the other hand, an implementation to enable perf to use
hw-breakpoint layer (and its APIs) to profile memory accesses over
kernel-space variables (in the context of a process) is very elegant,
modular and fits cleanly within the frame-work of the perf-events as a
new perf-type (refer http://lkml.org/lkml/2009/10/26/467). A working
patchset (under development and containing bugs) is posted for RFC here:
http://lkml.org/lkml/2009/10/26/461

It is my opinion that enhancing perf-layer to profile memory accesses
through hw-breakpoint layer should be preferred over merging them.

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 8) Posted: Thu Oct 29, 2009 3:20 pm
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

2009/10/26 K.Prasad <prasad RemoveThis @linux.vnet.ibm.com>:
> Outside the specific comments about the implementation here, I think
> the patchset begets a larger question about hw-breakpoint layer's
> integration with perf-events.
>
> Upon being a witness to the proposed changes and after some exploration
> of perf_events' functionality, I'm afraid that hw-breakpoint integration
> with perf doesn't benefit the former as much as originally wished to be
> (http://lkml.org/lkml/2009/8/26/149).
>
> Some of the prevalent concerns (which have been raised in different
> threads earlier) are:
>
> - While kernel-space breakpoints need to reside on every processor
>  (irrespective of the process in user-space), perf-events' notion of a
>  counter is always linked to a process context (although there could be
>  workarounds by making it 'pinned', etc).


No. A counter (let's talk about an event profiling instance now) is not
always attached to a single process.
It is attached to a context. Such contexts are defined by perf as gathering
a group of tasks or it can be a whole cpu.

The breakpoint API only supports two kind of contexts: one task, or every
cpus (or per cpu after your last patchset).

That said, perf events can be enhanced to support the context of a wide counter.


>
> - HW Breakpoints register allocation mechanism is 'greedy', which in my
>  opinion is more suitable for allocating a finite and contended
>  resource such as debug register while that of perf-events can give
>  rise to roll-backs (with side-effects such as stray exceptions and
>  race conditions).


I don't get your point. The only possible rollback is when we allocate
a wide breakpoint (then one per cpu).
If you worry about such races, we can register these breakpoints as
being disabled
and enable them once we know the allocation succeeded for every cpu.


>
> - Given that the notion of a per-process context for counters is
>  well-ingrained into the design of perf-events (even system-wide
>  counters are sometimes implemented through individual syscalls over
>  nr_cpus as in builtin-stat.c), it requires huge re-design and
>  user-space changes.


It doesn't require a huge redesign to support wide perf events.


> Trying to scoop out the hw-breakpoint layer off its book-keeping/register
> allocation features only to replace with that of perf-events leads to a
> poor retrofit. On the other hand, an implementation to enable perf to use
> hw-breakpoint layer (and its APIs) to profile memory accesses over
> kernel-space variables (in the context of a process) is very elegant,
> modular and fits cleanly within the frame-work of the perf-events as a
> new perf-type (refer http://lkml.org/lkml/2009/10/26/467). A working
> patchset (under development and containing bugs) is posted for RFC here:
> http://lkml.org/lkml/2009/10/26/461


The non-perf based api is fine for ptrace, kgdb and ftrace uses.
But it is too limited for perf use.

- It has an ad-hoc context binding (register scheduling) abstraction.
Perf is able to manage
that already: binding to defined group of processes, cpu, etc...

- It doesn't allow non-pinned events, when a breakpoint is disabled
(due to context schedule out), it is
only virtually disabled, it's slot is not freed.

Basically, the breakpoints are performance monitoring and debug
events. Something
that perf can already handle.

The current breakpoint API does all that in an ad-hoc way
(debug register scheduling when cpu get up/down, when we context
switch, etc...).
It is also not powerful enough to support non-pinned events.

The only downside I can see in perf events: it does not support wide
system contexts.
I don't think it requires a huge redesign. But instead of continuing
this ad-hoc context-handling
to cover this hole in perf, why not enhance perf so that it can cover that?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo RemoveThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
K.Prasad

External


Since: Dec 04, 2008
Posts: 27



(Msg. 9) Posted: Mon Nov 02, 2009 3:20 am
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Thu, Oct 29, 2009 at 08:07:15PM +0100, Frederic Weisbecker wrote:
> 2009/10/26 K.Prasad <prasad DeleteThis @linux.vnet.ibm.com>:
> > Outside the specific comments about the implementation here, I think
> > the patchset begets a larger question about hw-breakpoint layer's
> > integration with perf-events.
> >
> > Upon being a witness to the proposed changes and after some exploration
> > of perf_events' functionality, I'm afraid that hw-breakpoint integration
> > with perf doesn't benefit the former as much as originally wished to be
> > (http://lkml.org/lkml/2009/8/26/149).
> >
> > Some of the prevalent concerns (which have been raised in different
> > threads earlier) are:
> >
> > - While kernel-space breakpoints need to reside on every processor
> >  (irrespective of the process in user-space), perf-events' notion of a
> >  counter is always linked to a process context (although there could be
> >  workarounds by making it 'pinned', etc).
>
>
> No. A counter (let's talk about an event profiling instance now) is not
> always attached to a single process.
> It is attached to a context. Such contexts are defined by perf as gathering
> a group of tasks or it can be a whole cpu.
>

Okay.

> The breakpoint API only supports two kind of contexts: one task, or every
> cpus (or per cpu after your last patchset).
>

Yes, and please see the replies to your concerns below.

> That said, perf events can be enhanced to support the context of a wide counter.
>
>
> >
> > - HW Breakpoints register allocation mechanism is 'greedy', which in my
> >  opinion is more suitable for allocating a finite and contended
> >  resource such as debug register while that of perf-events can give
> >  rise to roll-backs (with side-effects such as stray exceptions and
> >  race conditions).
>
>
> I don't get your point. The only possible rollback is when we allocate
> a wide breakpoint (then one per cpu).
> If you worry about such races, we can register these breakpoints as
> being disabled
> and enable them once we know the allocation succeeded for every cpu.
>
>

Not just stray exceptions, as explained before here:
http://lkml.org/lkml/2009/10/1/76
- Races between the requests (also leading to temporary failure of
all CPU requests) presenting an unclear picture about free debug
registers (making it difficult to predict the need for a retry).

> >
> > - Given that the notion of a per-process context for counters is
> >  well-ingrained into the design of perf-events (even system-wide
> >  counters are sometimes implemented through individual syscalls over
> >  nr_cpus as in builtin-stat.c), it requires huge re-design and
> >  user-space changes.
>
>
> It doesn't require a huge redesign to support wide perf events.
>
>

I contest that Smile...and the sheer amount of code movement, re-design
(including core data structures) in the patchset here:
http://lkml.org/lkml/2009/10/24/53.
And all this with a loss of a well-layered, modular code and a
loss of true system-wide support for bkpt counters!

> > Trying to scoop out the hw-breakpoint layer off its book-keeping/register
> > allocation features only to replace with that of perf-events leads to a
> > poor retrofit. On the other hand, an implementation to enable perf to use
> > hw-breakpoint layer (and its APIs) to profile memory accesses over
> > kernel-space variables (in the context of a process) is very elegant,
> > modular and fits cleanly within the frame-work of the perf-events as a
> > new perf-type (refer http://lkml.org/lkml/2009/10/26/467). A working
> > patchset (under development and containing bugs) is posted for RFC here:
> > http://lkml.org/lkml/2009/10/26/461
>
>
> The non-perf based api is fine for ptrace, kgdb and ftrace uses.
> But it is too limited for perf use.
>
> - It has an ad-hoc context binding (register scheduling) abstraction.
> Perf is able to manage
> that already: binding to defined group of processes, cpu, etc...
>

I don't see what's ad-hoc in the scheduling behaviour of the hw-bkpt
layer. Hw-breakpoint layer does the following with respect to register
scheduling:

- User-space breakpoints are always tied to a thread
(thread_info/task_struct) and are hence
active when the corresponding thread is scheduled.

- Kernel-space addresses (requests from in-kernel sources) should be
always active and aren't affected by process context-switches/schedule
operations. Some of the sophisticated mechanisms for scheduling
kernel vs user-space breakpoints (such as trapping syscalls to restore
register context) were pre-empted by the community (as seen here:
http://lkml.org/lkml/2009/3/11/145).

Any further abstraction required by the end-user (as in the case of
perf) can be well-implemented through the powerful breakpoint
interfaces. For instance - perf-events with its unique requirement
wherein a kernel-space breakpoint need to be active only when a given
process is active. Hardware breakpoint layer handles them quite well
as seen here: http://lkml.org/lkml/2009/10/29/300.

> - It doesn't allow non-pinned events, when a breakpoint is disabled
> (due to context schedule out), it is
> only virtually disabled, it's slot is not freed.
>

The <enable><disable>_hw_breakpoint() are designed such. If a user want
the slot to be freed (which is ill-advised for a requirement here) it
can invoke (un)register_kernel_hw_breakpoint() instead (would have very
little overhead for the 1-CPU case without IPIs).

> Basically, the breakpoints are performance monitoring and debug
> events. Something
> that perf can already handle.
>
> The current breakpoint API does all that in an ad-hoc way
> (debug register scheduling when cpu get up/down, when we context
> switch, etc...).
> It is also not powerful enough to support non-pinned events.
>
> The only downside I can see in perf events: it does not support wide
> system contexts.
> I don't think it requires a huge redesign. But instead of continuing
> this ad-hoc context-handling
> to cover this hole in perf, why not enhance perf so that it can cover that?

The advantages of having perf-events to use hw-breakpoint layer is
explained here and in many of my previous emails. It entails no loss of
functionality for either perf-events of hw-breakpoints, while allowing
users to harness the power of both.

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 10) Posted: Mon Nov 02, 2009 9:20 am
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Mon, Nov 02, 2009 at 11:55:50AM +0530, K.Prasad wrote:
> > I don't get your point. The only possible rollback is when we allocate
> > a wide breakpoint (then one per cpu).
> > If you worry about such races, we can register these breakpoints as
> > being disabled
> > and enable them once we know the allocation succeeded for every cpu.
> >
> >
>
> Not just stray exceptions, as explained before here:
> http://lkml.org/lkml/2009/10/1/76
> - Races between the requests (also leading to temporary failure of
> all CPU requests) presenting an unclear picture about free debug
> registers (making it difficult to predict the need for a retry).



Ok. But say we have to set a wide breakpoint.
We can create a disabled set of per cpu breakpoint and then enable
them once we are sure every cpus can host it (we have already reserved a slot
for each of these while registering).

Then this race is not there anymore.


> > >
> > > - Given that the notion of a per-process context for counters is
> > >  well-ingrained into the design of perf-events (even system-wide
> > >  counters are sometimes implemented through individual syscalls over
> > >  nr_cpus as in builtin-stat.c), it requires huge re-design and
> > >  user-space changes.
> >
> >
> > It doesn't require a huge redesign to support wide perf events.
> >
> >
>
> I contest that Smile...and the sheer amount of code movement, re-design
> (including core data structures) in the patchset here:
> http://lkml.org/lkml/2009/10/24/53.



This is about rebasing the hw-breakpoints on top of another profiling
infrastructure.

So the fact we had to do a lot of changes looks fair.


> And all this with a loss of a well-layered, modular code and a
> loss of true system-wide support for bkpt counters!


I don't get your point about the loss of a well-layered and modular
code.

We are reusing an existing profiling infrastructure that looks pretty well
layered and modular to me:

The scheduling of per task registers is centralized in the core and not in the
arch like it was done with the hardware breakpoint api. The remaining arch bits
are only a concern of writing these registers.
It is not sane to hook on arch switch_to(), cpu hotplug helpers, kexec, etc...
to do an ad-hoc scheduling of perf task register whereas we already have
a centralized profiling area that can take these decisions.

So, yes indeed it doesn't support the wide contexts yet.

Let's compare that to the tracing area. What if we hadn't the tracepoints
and every tracers put their own tracing callbacks in the area they want to trace.
We would have a proliferation of ad-hoc tracing functions calls.
But we have the tracepoints: a centralized feature that only requires just one
callback somewhere in the kernel where we want to hook up and in which
every tracers can subscribe.
That's more modular and well-layered.

The problem with the lack of a wide context support with perf events is pretty
the same.
The hw-breakpoint api can implement its ad-hoc one. But it means every
other profiling/debug features will lack it and need to implement their
own.

So why not improving a centralized profiling subsystem instead of implementing
an ad-hoc one for every profiling classes that need it?



> > The non-perf based api is fine for ptrace, kgdb and ftrace uses.
> > But it is too limited for perf use.
> >
> > - It has an ad-hoc context binding (register scheduling) abstraction.
> > Perf is able to manage
> > that already: binding to defined group of processes, cpu, etc...
> >
>
> I don't see what's ad-hoc in the scheduling behaviour of the hw-bkpt
> layer. Hw-breakpoint layer does the following with respect to register
> scheduling:
>
> - User-space breakpoints are always tied to a thread
> (thread_info/task_struct) and are hence
> active when the corresponding thread is scheduled.



This is what is ad-hoc. You need to hook on switch_to, cpu hotplug
and kexec to update the breakpoints registers. And this is something
that would need to be done in every archs. That looks insane considering
the fact we have a core layer that can handle these decisions already.



> - Kernel-space addresses (requests from in-kernel sources) should be
> always active and aren't affected by process context-switches/schedule
> operations. Some of the sophisticated mechanisms for scheduling
> kernel vs user-space breakpoints (such as trapping syscalls to restore
> register context) were pre-empted by the community (as seen here:
> http://lkml.org/lkml/2009/3/11/145).



Sure. And things have evolved since then. We have a centralized
profiling/event susbsystem now.



> Any further abstraction required by the end-user (as in the case of
> perf) can be well-implemented through the powerful breakpoint
> interfaces. For instance - perf-events with its unique requirement
> wherein a kernel-space breakpoint need to be active only when a given
> process is active. Hardware breakpoint layer handles them quite well
> as seen here: http://lkml.org/lkml/2009/10/29/300.




It logically disables/enables the breakpoints but not physically.
Which means a disabled breakpoint still keeps its slot, making
it unavailable for another event, it i required for non-pinned
events.




> > - It doesn't allow non-pinned events, when a breakpoint is disabled
> > (due to context schedule out), it is
> > only virtually disabled, it's slot is not freed.
> >
>
> The <enable><disable>_hw_breakpoint() are designed such. If a user want
> the slot to be freed (which is ill-advised for a requirement here) it
> can invoke (un)register_kernel_hw_breakpoint() instead (would have very
> little overhead for the 1-CPU case without IPIs).


This adds unnecessary overhead. All we want is to update arch registers
when we schedule in/out an event.

We need to be able to free a slot for non-pinned counter because
an undefined number of events must be able to be time shared
in a single slot (in the worst case).

Calling unregister_kernel_breakpoint() each time we schedule out
a non-pinned counter adds unnecessary overhead. And calling
register_kernel_breakpoint() while enabling one is yet
another unnecessary overhead.

You'd need to check the free slots constraints every time for them.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.DeleteThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
K.Prasad

External


Since: Dec 04, 2008
Posts: 27



(Msg. 11) Posted: Wed Nov 04, 2009 9:20 am
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Mon, Nov 02, 2009 at 03:07:14PM +0100, Frederic Weisbecker wrote:
> On Mon, Nov 02, 2009 at 11:55:50AM +0530, K.Prasad wrote:
> > > I don't get your point. The only possible rollback is when we allocate
> > > a wide breakpoint (then one per cpu).
> > > If you worry about such races, we can register these breakpoints as
> > > being disabled
> > > and enable them once we know the allocation succeeded for every cpu.
> > >
> > >
> >
> > Not just stray exceptions, as explained before here:
> > http://lkml.org/lkml/2009/10/1/76
> > - Races between the requests (also leading to temporary failure of
> > all CPU requests) presenting an unclear picture about free debug
> > registers (making it difficult to predict the need for a retry).
>
>
>
> Ok. But say we have to set a wide breakpoint.
> We can create a disabled set of per cpu breakpoint and then enable
> them once we are sure every cpus can host it (we have already reserved a slot
> for each of these while registering).
>
> Then this race is not there anymore.
>

Let me explain further with an illustration..assume two contenders for
breakpoints say A and B on a machine with 4 CPUs (0-3). Due to several
prior per-CPU requests CPU0 has one free debug register while CPU3 has
none. 'A' asks for a system-wide breakpoint while 'B' requests for a
per-cpu breakpoint on CPU0. Now think of a race between them! If 'A'
begins first, it starts with CPU0 and proceeds by consuming debug
registers on CPUs in ascending order, meanwhile 'B' would return
thinking that its request cannot be serviced. However 'A' would
eventually fail (since there are no free debug registers on CPU3) and
relinquish the debug register on CPU0 also (during rollback), but 'B'
has returned thinking that there are no free debug registers available.
(registering breakpoint requests in disabled state only helps prevent stray
exceptions).

With some book-keeping such races are prevented. Registration requests
would fail with -ENOSPC only if there are genuine users of debug
registers and not because some potential user (who might eventually
rollback) is holding onto the register temporarily.

Such a limitation may not be of immediate worry, but shouldn't be
a reason to throw away a feature that pre-empts such concerns. Are there
any hw-registers managed by perf-events that are more than one (like
debug registers which are 4 in x86) with such peculiar needs?

> > > >
> > > > - Given that the notion of a per-process context for counters is
> > > >  well-ingrained into the design of perf-events (even system-wide
> > > >  counters are sometimes implemented through individual syscalls over
> > > >  nr_cpus as in builtin-stat.c), it requires huge re-design and
> > > >  user-space changes.
> > >
> > >
> > > It doesn't require a huge redesign to support wide perf events.
> > >
> > >
> >
> > I contest that Smile...and the sheer amount of code movement, re-design
> > (including core data structures) in the patchset here:
> > http://lkml.org/lkml/2009/10/24/53.
>
>
>
> This is about rebasing the hw-breakpoints on top of another profiling
> infrastructure.
>
> So the fact we had to do a lot of changes looks fair.
>
>
> > And all this with a loss of a well-layered, modular code and a
> > loss of true system-wide support for bkpt counters!
>
>
> I don't get your point about the loss of a well-layered and modular
> code.
>
> We are reusing an existing profiling infrastructure that looks pretty well
> layered and modular to me:
>
> The scheduling of per task registers is centralized in the core and not in the
> arch like it was done with the hardware breakpoint api. The remaining arch bits
> are only a concern of writing these registers.
> It is not sane to hook on arch switch_to(), cpu hotplug helpers, kexec, etc...
> to do an ad-hoc scheduling of perf task register whereas we already have
> a centralized profiling area that can take these decisions.
>
> So, yes indeed it doesn't support the wide contexts yet.
>

User-space scheduling of breakpoint register is the closest that
comes to what perf-events already does...and that's just about a
single-hook in __switch_to(). Have no delusions about huge
duplication! and no concerns about arch-specific code being littered all
over - writing onto debug registers is a processor-specific activity and
hence the arch-specific invocation.

System-wide breakpoints, cpu hotplug helpers, kexec hooks as you
mentioned have not been implemented for perf-events....and in a way it
is of little help there other than for hw-breakpoints (are there any
hw-registers managed by perf that have residual effect i.e. continue to
generate exceptions like hw-breakpoints?)

> Let's compare that to the tracing area. What if we hadn't the tracepoints
> and every tracers put their own tracing callbacks in the area they want to trace.
> We would have a proliferation of ad-hoc tracing functions calls.
> But we have the tracepoints: a centralized feature that only requires just one
> callback somewhere in the kernel where we want to hook up and in which
> every tracers can subscribe.
> That's more modular and well-layered.
>

Comparing this to tracepoints isn't apt here. My limited knowledge
doesn't quickly provide me with an alternate analogy (how about kprobes
+ perf-events integration?...no, even that isn't close).

> The problem with the lack of a wide context support with perf events is pretty
> the same.
> The hw-breakpoint api can implement its ad-hoc one. But it means every
> other profiling/debug features will lack it and need to implement their
> own.
>

Can you cite the need for such features in general perf-events
architecture with examples other than hw-breakpoints? In my opinion, if there
had been a need, perf-events would have included them already (perf top
is the only need that comes close to wanting system-wide support but
even there, it is happy by making one syscall per-cpu).

Integrating the features required by hw-breakpoints with perf-events
(with apologies for the out-of-context examples) like mixing oil with
water, proverbial chalk-and-cheese....they stay together but are
immiscible.

Citing some examples from your patchset, look at the addition of
'callback' function pointer or the addition of length, type fields in
perf_event_attr. Do you find generic use-cases for them in perf-events
(outside hw-breakpoints)? Merging structures to create a generic one,
but only to be used for a specific use-case (hw-breakpoint) doesn't
sound like a good idea, and speculating on future use-cases (not current
ones) have never been welcomed.

> So why not improving a centralized profiling subsystem instead of implementing
> an ad-hoc one for every profiling classes that need it?
>
>
>
> > > The non-perf based api is fine for ptrace, kgdb and ftrace uses.
> > > But it is too limited for perf use.
> > >
> > > - It has an ad-hoc context binding (register scheduling) abstraction.
> > > Perf is able to manage
> > > that already: binding to defined group of processes, cpu, etc...
> > >
> >
> > I don't see what's ad-hoc in the scheduling behaviour of the hw-bkpt
> > layer. Hw-breakpoint layer does the following with respect to register
> > scheduling:
> >
> > - User-space breakpoints are always tied to a thread
> > (thread_info/task_struct) and are hence
> > active when the corresponding thread is scheduled.
>
>
>
> This is what is ad-hoc. You need to hook on switch_to, cpu hotplug
> and kexec to update the breakpoints registers. And this is something
> that would need to be done in every archs. That looks insane considering
> the fact we have a core layer that can handle these decisions already.
>
>

As explained above.

>
> > - Kernel-space addresses (requests from in-kernel sources) should be
> > always active and aren't affected by process context-switches/schedule
> > operations. Some of the sophisticated mechanisms for scheduling
> > kernel vs user-space breakpoints (such as trapping syscalls to restore
> > register context) were pre-empted by the community (as seen here:
> > http://lkml.org/lkml/2009/3/11/145).
>
>
> Sure. And things have evolved since then. We have a centralized
> profiling/event susbsystem now.
>
>
> > Any further abstraction required by the end-user (as in the case of
> > perf) can be well-implemented through the powerful breakpoint
> > interfaces. For instance - perf-events with its unique requirement
> > wherein a kernel-space breakpoint need to be active only when a given
> > process is active. Hardware breakpoint layer handles them quite well
> > as seen here: http://lkml.org/lkml/2009/10/29/300.
>
>
> It logically disables/enables the breakpoints but not physically.
> Which means a disabled breakpoint still keeps its slot, making
> it unavailable for another event, it i required for non-pinned
> events.
>
> > > - It doesn't allow non-pinned events, when a breakpoint is disabled
> > > (due to context schedule out), it is
> > > only virtually disabled, it's slot is not freed.
> > >
> >
> > The <enable><disable>_hw_breakpoint() are designed such. If a user want
> > the slot to be freed (which is ill-advised for a requirement here) it
> > can invoke (un)register_kernel_hw_breakpoint() instead (would have very
> > little overhead for the 1-CPU case without IPIs).
>
>
> This adds unnecessary overhead. All we want is to update arch registers
> when we schedule in/out an event.
>
> We need to be able to free a slot for non-pinned counter because
> an undefined number of events must be able to be time shared
> in a single slot (in the worst case).
>
> Calling unregister_kernel_breakpoint() each time we schedule out
> a non-pinned counter adds unnecessary overhead. And calling
> register_kernel_breakpoint() while enabling one is yet
> another unnecessary overhead.
>
> You'd need to check the free slots constraints every time for them.
>

As I told you register/unregister combination is to be used, and I can
get you some numbers about its overhead if that is of concern to you.
It is the IPI constitues a large overhead (not needed for a 1-cpu request),
and not the book-keeping work. A more elegant way would be to use the
modify_kernel_hw_breakpoint() (interface submitted in one of my previous
patches) to simply change the breakpoint address/type/len.

I don't see anything that is required by the perf-event that the
hw-breakpoint layer doesn't provide.

I shall re-state these views in a response to Ingo's mail (that talks about
concerns of duplicate code)...meanwhile I think I should begin
reviewing your patchset (for perf-integration) lest the community insist
that approach.

Thanks,
K.Prasad

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo DeleteThis @vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Frederic Weisbecker

External


Since: Nov 03, 2008
Posts: 364



(Msg. 12) Posted: Thu Nov 05, 2009 7:21 am
Post subject: Re: [GIT PULL v2] hw-breakpoints: Rewrite on top of perf events [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

On Wed, Nov 04, 2009 at 07:44:25PM +0530, K.Prasad wrote:
> Let me explain further with an illustration..assume two contenders for
> breakpoints say A and B on a machine with 4 CPUs (0-3). Due to several
> prior per-CPU requests CPU0 has one free debug register while CPU3 has
> none. 'A' asks for a system-wide breakpoint while 'B' requests for a
> per-cpu breakpoint on CPU0. Now think of a race between them! If 'A'
> begins first, it starts with CPU0 and proceeds by consuming debug
> registers on CPUs in ascending order, meanwhile 'B' would return
> thinking that its request cannot be serviced. However 'A' would
> eventually fail (since there are no free debug registers on CPU3) and
> relinquish the debug register on CPU0 also (during rollback), but 'B'
> has returned thinking that there are no free debug registers available.
> (registering breakpoint requests in disabled state only helps prevent stray
> exceptions).
>
> With some book-keeping such races are prevented. Registration requests
> would fail with -ENOSPC only if there are genuine users of debug
> registers and not because some potential user (who might eventually
> rollback) is holding onto the register temporarily.


True. But such race would only happen in case of concurrent launching
of perf and the ksym_tracer or kgdb in parallel.

I can't figure out such situation to happen easily.
But if that's really a worry, we can lock the register_breakpoint_*
path (or implement wide perf events).


> Such a limitation may not be of immediate worry, but shouldn't be
> a reason to throw away a feature that pre-empts such concerns.



When you migrate a feature on top of another subsystem, it happens
you can lose something. If the migration induces nice new features
then sometimes it's worth the migration and add some code to break
the loss.

But if the loss is about such a tiny tight race that is unlikely
to happen in the real world (and doesn't imply crash or something
bad like that) then it's not necessary worth the effort.


> Are there
> any hw-registers managed by perf-events that are more than one (like
> debug registers which are 4 in x86) with such peculiar needs?


Perhaps. I don't know. If so, we may want to migrate the plural pmu
constraints from hw_breakpoint.c to perf_event.c.

That said this is likely to happen because we don't need registers for that.
Any profiling/tracing/debugging unit based on multiple sources and bound
to tunable contexts may fit into that scheme.
Hardware registers are just a subset of what can be considered as a
a source of "performance monitoring unit".

And perf event has been extended enough to expand the possible
sources to "Event monitoring unit", so the possibilities are broad.



> User-space scheduling of breakpoint register is the closest that
> comes to what perf-events already does...and that's just about a
> single-hook in __switch_to(). Have no delusions about huge
> duplication! and no concerns about arch-specific code being littered all
> over - writing onto debug registers is a processor-specific activity and
> hence the arch-specific invocation.



That's because it's so close to perf event context scheduling that
we want to unify it.

This is not only a single hook in __switch_to():

- This is a context bound ressource scheduling decision made from arch
in spite of the existing optimized mechanisms implemented in a core
profiling subsystem.

- This is a single hook in __switch_to() in x86. Now multiply that
by $(ls arch/ | wc -l) = 26 (-1 because of arch/Kconfig)
Also, expand that to cpu hotplug hooks, kexec hooks, etc...
And also include the free_thread hooks.

- If we have a ptrace breakpoint, the scheduling decision is made
by the hw_breakpoint API. Otherwise it's made by perf.
Why should we maintain two versions of the scheduling decision?

This is a matter of maintainabilty.


> System-wide breakpoints, cpu hotplug helpers, kexec hooks as you
> mentioned have not been implemented for perf-events....and in a way it
> is of little help there other than for hw-breakpoints (are there any
> hw-registers managed by perf that have residual effect i.e. continue to
> generate exceptions like hw-breakpoints?)



System wide events are not supported by perf because of a
design decision for scalability ends.

Each event is bound to a private buffer (inherited to task
childs in the case of task bound counters).
If we have an event that can trigger from every cpu, we can
have multiple concurrent writes in the same buffer and the
profiling would suffer from such contention if we have a
lot of events from several cpus.

Having cpu bound events drop this contention as the events don't
fight against other cpus.

(It the case of task bound events, the contention is there, but
in the window of a task group only).

We manage a wide profiling using a collection of per cpu events,
it scales way much better.

We could also implement the wide context if that becomes wanted but
it should be used by knowing that it won't scale for high frequency
events in SMP.

Concerning cpu hotplug helpers, it is implemented by perf events
(perf_event_{exit/init}_cpu() notifiers).

Kexec is a corner case, but we might want to add a kexec callback
to the pmu structure if needed.

Concerning residual effects of lazy breakpoint registers switching
I don't how the migration to perf brings any problem.


> Comparing this to tracepoints isn't apt here. My limited knowledge
> doesn't quickly provide me with an alternate analogy (how about kprobes
> + perf-events integration?...no, even that isn't close).



Why isn't the tracepoint analogy apt?

It's basically the same.

Say you have func1(), a function in which several subsystems want
to hook:


func1()
{
// do something cool
subsys1_hook();
subsys2_hook();
subsys3_hook();
etc...
}

Instead of that, we can use tracepoint, so that we can zap all
these hooks and only provide one that will dispatch to the subsys:

func1()
{
trace_func1() -> will dispatch to subsys1_hook(), subsys2_hook() etc..
}

The current situation with hw breakpoints and perf is somehow the same.
Hw breakpoint is hooking at arch __switch_to(), cpu_hotplug thing, etc...

But perf too. And perf can act as a dispatcher there. It already
hooks on the scheduler events and cpu hotplug and can take
centralized decisions from these hooks, such as toggling pmus,
and hardware breakpoints can fit there.


> Can you cite the need for such features in general perf-events
> architecture with examples other than hw-breakpoints? In my opinion, if there
> had been a need, perf-events would have included them already (perf top
> is the only need that comes close to wanting system-wide support but
> even there, it is happy by making one syscall per-cpu).



It is happy doing so because it scales.



> Integrating the features required by hw-breakpoints with perf-events
> (with apologies for the out-of-context examples) like mixing oil with
> water, proverbial chalk-and-cheese....they stay together but are
> immiscible.
>
> Citing some examples from your patchset, look at the addition of
> 'callback' function pointer or the addition of length, type fields in
> perf_event_attr. Do you find generic use-cases for them in perf-events
> (outside hw-breakpoints)? Merging structures to create a generic one,
> but only to be used for a specific use-case (hw-breakpoint) doesn't
> sound like a good idea, and speculating on future use-cases (not current
> ones) have never been welcomed.



We need to give the parameters for this specific event. The current
struct perf_event_attr is not sufficient for that.
It needs to grow if needed to host new needs for new events. That's
why it has a field for its size, that's why it has reserved fields,
I don't see where is the problem with that. Nothing in the breakpoint
API can help about that either. We still need a suitable userspace
gate to define a breakpoint.

And while at it, we reuse it for in-kernel uses.

If you look at the struct hw_perf_event, you'll find a protean
structure, considering the union inside, so that it can fit the needs
for two different type of events.


> As I told you register/unregister combination is to be used, and I can
> get you some numbers about its overhead if that is of concern to you.
> It is the IPI constitues a large overhead (not needed for a 1-cpu request),
> and not the book-keeping work. A more elegant way would be to use the
> modify_kernel_hw_breakpoint() (interface submitted in one of my previous
> patches) to simply change the breakpoint address/type/len.



And btw the IPI that binds an event to a cpu is another example of
something already managed by perf.

My real concern is about the fact that the hw-breakpoint api
would act as an unnecessary midlayer there.
Perf is already able to talk directly to the pmu to enable/disable it,
which in practice is just a write to the debug registers.

Why should we encumber with such midlayer?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo.RemoveThis@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Login to vote
Display posts from previous:   
Related Topics:
Picasso Events Team - Take the Lead with Us! www.picassome.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel&...

vmstat: use our own timer events - vmstat is currently using the cache reaper to periodically bring the statistics up to date. The cache reaper does only....

[GIT-PULL] please pull UBI tree - Linus, please, pull UBI tree from git://git.infradead.org/ubi-2.6.git for-linus The UBI tree has been in -mm for..

netlink messages on ARP events - Hi, I'm experimenting with NETLINK_ROUTE socket on 2.6.16 (patched with mipl - mobile ipv6 for linux), in order to..

user defined hotplug events? - Hello, on my notebook, the built in wlan card uses the ipw2100 driver. On boot time, the ipw2100 module is loaded and....

x86 setup code rewrite in C - This patch set replaces the x86 setup code, which is currently all in assembly, with a version written in C, using the....
       Soft32 Home -> Linux -> Kernel All times are: Pacific Time (US & Canada) (change)
Page 1 of 1

 
You can post new topics in this forum
You can reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Categories:
 Windows
  Linux
 Mac
 PDA


[ Contact us | Terms of Service/Privacy Policy ]