From: "K.Prasad" <prasad@linux.vnet.ibm.com>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Lai Jiangshan <laijs@cn.fujitsu.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Alan Stern <stern@rowland.harvard.edu>
Subject: [Patch 0/1] HW-BKPT: Allow per-cpu kernel-space Hardware Breakpoint requests
Date: Mon, 17 Aug 2009 18:16:41 +0530 [thread overview]
Message-ID: <20090817124641.GA13354@in.ibm.com> (raw)
Hi All,
Please find a patch that enables kernel-space breakpoints to be
requested for a subset of the available CPUs in the system. This allows
per-CPU breakpoints and comes with the associated benefit of reduced
overhead during (un)registration.
This enhancement allows exploitation of hardware breakpoint registers by
'perf' which produces a CPU-wise information.
Design changes
--------------
- Every breakpoint request 'consumes' the first available debug register
(starting from HBP_NUM) in each CPU represented by 'cpumask' field in
'struct hw_breakpoint'.
- 'hbp_kernel_pos' (that separates kernel-space breakpoints from the
free/user-space breakpoints) now points to the maximum of debug
registers consumed on any given CPU.
-- 'hbp_kernel_pos' is decremented (one-at-a-time) to allow a new-slot
for kernel-space requests iff all debug registers on the given CPU
(from HBP_NUM - 1 to 'hbp_kernel_pos' are already consumed.
-- 'hbp_kernel_pos' is incremented (one-at-a-time) to free a slot iff
a removal request results in the release of a bkpt request that
consumed maximum debug registers for kernel-space.
- Every removal request results in compaction of breakpoint registers
(on a per-cpu basis) to occupy the vacant debug register.
The patch is based on commit b6c720b811aed0eeda89f277f13c1bd1bdf721fd of
-tip tree and has been tested to work fine on an x86 machine for both
cases (i.e. system-wide kernel breakpoints and bkpts for a subset of CPUs).
Please let me know your comments on the same.
Thanks,
K.Prasad
next reply other threads:[~2009-08-17 12:46 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-17 12:46 K.Prasad [this message]
2009-08-19 16:11 ` K.Prasad
2009-08-19 17:33 ` Frederic Weisbecker
2009-08-20 17:27 ` K.Prasad
2009-08-21 14:28 ` Ingo Molnar
2009-08-26 3:36 ` Frederic Weisbecker
2009-08-26 9:16 ` Ingo Molnar
2009-08-26 11:49 ` Frederic Weisbecker
2009-08-26 18:02 ` K.Prasad
2009-08-29 13:41 ` Ingo Molnar
2009-09-01 6:38 ` K.Prasad
2009-09-01 23:51 ` Frederic Weisbecker
2009-09-03 18:28 ` K.Prasad
2009-09-03 19:22 ` Ingo Molnar
2009-08-25 20:33 ` K.Prasad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090817124641.GA13354@in.ibm.com \
--to=prasad@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=fweisbec@gmail.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=stern@rowland.harvard.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome