On 04/25, Jacob Shin wrote:
>
> Right now perf
> userland tool hard codes bp_len to 4, so I need to modify it to allow
> user to override the length if desired.
imho this itself looks like a good change...
> Oleg, Frederic, et al.
>
> Which syntax do you prefer?
>
> $ perf stat -e
On Fri, Apr 26, 2013 at 05:20:44PM +0100, Will Deacon wrote:
> Hi Jacob,
>
> On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
> > On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> > > On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> > > >>
> > > >> The downside is that in
Hi Jacob,
On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
> On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> > On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> > >>
> > >> The downside is that in userland perf tool we need differing
> > >> documentation
> > >> on what
Hi Jacob,
On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
The downside is that in userland perf tool we need differing
documentation
on what the mask syntax
On Fri, Apr 26, 2013 at 05:20:44PM +0100, Will Deacon wrote:
Hi Jacob,
On Fri, Apr 26, 2013 at 12:19:11AM +0100, Jacob Shin wrote:
On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
The downside is that in userland perf
On 04/25, Jacob Shin wrote:
Right now perf
userland tool hard codes bp_len to 4, so I need to modify it to allow
user to override the length if desired.
imho this itself looks like a good change...
Oleg, Frederic, et al.
Which syntax do you prefer?
$ perf stat -e mem:0x1000/16
On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
> On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
> >>
> >> The downside is that in userland perf tool we need differing documentation
> >> on what the mask syntax means for each architecture.
> >
> > Personally I think this is
On 04/25, Jacob Shin wrote:
>
> On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
> > On 04/25, Frederic Weisbecker wrote:
> > >
> > > Do we need len and mask to work at the same time? I can't think of a
> > > situation when len and mask mix up together in a useful way to define
> > >
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
>>
>> The downside is that in userland perf tool we need differing documentation
>> on what the mask syntax means for each architecture.
>
> Personally I think this is acceptable.
>
> But I am new to this code, so...
>
That would seem really, really
On 04/24, Jacob Shin wrote:
>
> And only x86
> hw_breakpoint will know what .config = 0xf means for x86 and do the right
> thing. For ARM, 0xf will mean something different.
>
> The downside is that in userland perf tool we need differing documentation
> on what the mask syntax means for each
On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
> On 04/25, Frederic Weisbecker wrote:
> >
> > 2013/4/23 Jacob Shin :
> > > @@ -286,7 +286,10 @@ struct perf_event_attr {
> > > __u64 config1; /* extension of config */
> > > };
> > > union {
>
On 04/25, Oleg Nesterov wrote:
>
> On 04/25, Frederic Weisbecker wrote:
> >
> > 2013/4/23 Jacob Shin :
> > > @@ -286,7 +286,10 @@ struct perf_event_attr {
> > > __u64 config1; /* extension of config */
> > > };
> > > union {
> > > - __u64
On 04/25, Frederic Weisbecker wrote:
>
> 2013/4/23 Jacob Shin :
> > @@ -286,7 +286,10 @@ struct perf_event_attr {
> > __u64 config1; /* extension of config */
> > };
> > union {
> > - __u64 bp_len;
> > + struct {
> > +
On 04/25, Frederic Weisbecker wrote:
2013/4/23 Jacob Shin jacob.s...@amd.com:
@@ -286,7 +286,10 @@ struct perf_event_attr {
__u64 config1; /* extension of config */
};
union {
- __u64 bp_len;
+ struct {
On 04/25, Oleg Nesterov wrote:
On 04/25, Frederic Weisbecker wrote:
2013/4/23 Jacob Shin jacob.s...@amd.com:
@@ -286,7 +286,10 @@ struct perf_event_attr {
__u64 config1; /* extension of config */
};
union {
- __u64
On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
On 04/25, Frederic Weisbecker wrote:
2013/4/23 Jacob Shin jacob.s...@amd.com:
@@ -286,7 +286,10 @@ struct perf_event_attr {
__u64 config1; /* extension of config */
};
union {
On 04/24, Jacob Shin wrote:
And only x86
hw_breakpoint will know what .config = 0xf means for x86 and do the right
thing. For ARM, 0xf will mean something different.
The downside is that in userland perf tool we need differing documentation
on what the mask syntax means for each
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
The downside is that in userland perf tool we need differing documentation
on what the mask syntax means for each architecture.
Personally I think this is acceptable.
But I am new to this code, so...
That would seem really, really awkward.
On 04/25, Jacob Shin wrote:
On Thu, Apr 25, 2013 at 05:10:35PM +0200, Oleg Nesterov wrote:
On 04/25, Frederic Weisbecker wrote:
Do we need len and mask to work at the same time? I can't think of a
situation when len and mask mix up together in a useful way to define
a range.
On Thu, Apr 25, 2013 at 10:17:35AM -0700, H. Peter Anvin wrote:
On 04/25/2013 10:06 AM, Oleg Nesterov wrote:
The downside is that in userland perf tool we need differing documentation
on what the mask syntax means for each architecture.
Personally I think this is acceptable.
But I
2013/4/23 Jacob Shin :
> From: Jacob Shin
> Date: Mon, 22 Apr 2013 17:02:37 -0500
> Subject: [PATCH 1/4] perf: Add hardware breakpoint address mask
>
> Some architectures (for us, AMD Family 16h) allow for "don't care" bit
> mask to further qualify a hardware breakpoint address, in order to
>
On Wed, Apr 24, 2013 at 10:48:53AM +0100, Will Deacon wrote:
> On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
> > On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
> > > On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> > > > > perf stat -e mem:0x1000/0xf:w
On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
> On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
> > On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> > > > perf stat -e mem:0x1000/0xf:w a.out
> >
> > Are you saying that this command would count any write
On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
perf stat -e mem:0x1000/0xf:w a.out
Are you saying that this command would count any write to:
On Wed, Apr 24, 2013 at 10:48:53AM +0100, Will Deacon wrote:
On Tue, Apr 23, 2013 at 04:18:46PM +0100, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
perf stat -e mem:0x1000/0xf:w a.out
2013/4/23 Jacob Shin jacob.s...@amd.com:
From: Jacob Shin jacob.s...@amd.com
Date: Mon, 22 Apr 2013 17:02:37 -0500
Subject: [PATCH 1/4] perf: Add hardware breakpoint address mask
Some architectures (for us, AMD Family 16h) allow for don't care bit
mask to further qualify a hardware
On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
> On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> > On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
> > > On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
> > > > Can you see a problem if I simply
On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
> On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
> > On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
> > > Can you see a problem if I simply invert the mask?
> >
> > That's great! No, I don't see a problem at
On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
> On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
> > Hi Jacob,
> >
> > On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
> > > Some architectures (for us, AMD Family 16h) allow for "don't care" bit
> > > mask to
On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
> Hi Jacob,
>
> On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
> > Some architectures (for us, AMD Family 16h) allow for "don't care" bit
> > mask to further qualify a hardware breakpoint address, in order to
> > trap on
On Tue, Apr 23, 2013 at 03:18:44PM +0200, Oleg Nesterov wrote:
> On 04/23, Jacob Shin wrote:
> >
> > +__weak int arch_validate_hwbkpt_addr_mask(struct perf_event *bp)
> > +{
> > + return bp->attr.bp_addr_mask == 0;
> > +}
> > +
> > static int validate_hw_breakpoint(struct perf_event *bp)
> > {
On 04/23, Jacob Shin wrote:
>
> +__weak int arch_validate_hwbkpt_addr_mask(struct perf_event *bp)
> +{
> + return bp->attr.bp_addr_mask == 0;
> +}
> +
> static int validate_hw_breakpoint(struct perf_event *bp)
> {
> int ret;
> @@ -393,6 +398,10 @@ static int
Hi Jacob,
On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
> Some architectures (for us, AMD Family 16h) allow for "don't care" bit
> mask to further qualify a hardware breakpoint address, in order to
> trap on range of addresses. Update perf uapi to add bp_addr_mask field.
arm and
Some architectures (for us, AMD Family 16h) allow for "don't care" bit
mask to further qualify a hardware breakpoint address, in order to
trap on range of addresses. Update perf uapi to add bp_addr_mask field.
Signed-off-by: Jacob Shin
---
include/uapi/linux/perf_event.h |5 -
Some architectures (for us, AMD Family 16h) allow for don't care bit
mask to further qualify a hardware breakpoint address, in order to
trap on range of addresses. Update perf uapi to add bp_addr_mask field.
Signed-off-by: Jacob Shin jacob.s...@amd.com
---
include/uapi/linux/perf_event.h |5
Hi Jacob,
On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
Some architectures (for us, AMD Family 16h) allow for don't care bit
mask to further qualify a hardware breakpoint address, in order to
trap on range of addresses. Update perf uapi to add bp_addr_mask field.
arm and arm64
On 04/23, Jacob Shin wrote:
+__weak int arch_validate_hwbkpt_addr_mask(struct perf_event *bp)
+{
+ return bp-attr.bp_addr_mask == 0;
+}
+
static int validate_hw_breakpoint(struct perf_event *bp)
{
int ret;
@@ -393,6 +398,10 @@ static int validate_hw_breakpoint(struct
On Tue, Apr 23, 2013 at 03:18:44PM +0200, Oleg Nesterov wrote:
On 04/23, Jacob Shin wrote:
+__weak int arch_validate_hwbkpt_addr_mask(struct perf_event *bp)
+{
+ return bp-attr.bp_addr_mask == 0;
+}
+
static int validate_hw_breakpoint(struct perf_event *bp)
{
int ret;
On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
Hi Jacob,
On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
Some architectures (for us, AMD Family 16h) allow for don't care bit
mask to further qualify a hardware breakpoint address, in order to
trap on range of
On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
Hi Jacob,
On Tue, Apr 23, 2013 at 08:57:02AM +0100, Jacob Shin wrote:
Some architectures (for us, AMD Family 16h) allow for don't care bit
mask to further qualify
On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
Can you see a problem if I simply invert the mask?
That's great! No, I don't see a problem at all.
Great!
On Tue, Apr 23, 2013 at 04:02:40PM +0100, Will Deacon wrote:
On Tue, Apr 23, 2013 at 03:40:57PM +0100, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 09:34:23AM -0500, Jacob Shin wrote:
On Tue, Apr 23, 2013 at 10:54:37AM +0100, Will Deacon wrote:
Can you see a problem if I simply invert the
42 matches
Mail list logo
