* Peter Zijlstra wrote:
> On Fri, 2012-09-14 at 22:11 +0200, Ingo Molnar wrote:
> > return -EPERF_CPU_PRECISE_EV_NOTSUPP;
>
> I just don't like having to enumerate all possible fails, I'm
> too lazy. Can't we be smarter about that? Could we do a
> {reason}x{bit-offset} like thing?
>
> Wher
On Fri, 2012-09-14 at 22:11 +0200, Ingo Molnar wrote:
> return -EPERF_CPU_PRECISE_EV_NOTSUPP;
I just don't like having to enumerate all possible fails, I'm too lazy.
Can't we be smarter about that? Could we do a {reason}x{bit-offset} like
thing?
Where we limit reason to a few simple things like
* Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
> > On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > > > Understood and there have been suggestions on how to definitely state
> > > > what the kernel side did not like. I like Peter's last suggestion --
> > > > something a
* Peter Zijlstra wrote:
> On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > > Understood and there have been suggestions on how to definitely state
> > > what the kernel side did not like. I like Peter's last suggestion --
> > > something along the lines of clearing attr on
On Fri, 2012-09-14 at 11:00 -0700, Arnaldo Carvalho de Melo wrote:
> > Understood and there have been suggestions on how to definitely state
> > what the kernel side did not like. I like Peter's last suggestion --
> > something along the lines of clearing attr on a failure except the
> > offending
Em Fri, Sep 14, 2012 at 05:43:42AM -0600, David Ahern escreveu:
> On 9/14/12 5:36 AM, Ingo Molnar wrote:
> >Well, then that is useful information we *lost*, and that situation
> >needs to be improved on the ABI side: an expanded error code present
> >in the event structure, copied back to user-spa
On 9/14/12 5:36 AM, Ingo Molnar wrote:
Well, then that is useful information we *lost*, and that
situation needs to be improved on the ABI side: an expanded
error code present in the event structure, copied back to
user-space on errors, or so.
(Alternatively, a special event channel just to pass
* David Ahern wrote:
> On 9/13/12 11:43 PM, Ingo Molnar wrote:
> >>v2: softened message to 'may not be' supported per Robert's suggestion
> >
> > Well, either it's supported on this machine or it's not -
> > why does the text have to be so unsure about it?
>
> Because EOPNOTSUPP is returned fo
On 9/13/12 11:43 PM, Ingo Molnar wrote:
v2: softened message to 'may not be' supported per Robert's suggestion
Well, either it's supported on this machine or it's not - why
does the text have to be so unsure about it?
Because EOPNOTSUPP is returned for more than just precise mode. We
cannot
* David Ahern wrote:
> Platforms (e.g., VM's) without support for precise mode get a confusing
> error message. e.g.,
> $ perf record -e cycles:p -a -- sleep 1
>
> Error: sys_perf_event_open() syscall returned with 95 (Operation not
> supported). /bin/dmesg may provide additional informati
Platforms (e.g., VM's) without support for precise mode get a confusing
error message. e.g.,
$ perf record -e cycles:p -a -- sleep 1
Error: sys_perf_event_open() syscall returned with 95 (Operation not
supported). /bin/dmesg may provide additional information.
No hardware sampling interrup
Platforms (e.g., VM's) without support for precise mode get a confusing
error message. e.g.,
$ perf record -e cycles:p -a -- sleep 1
Error: sys_perf_event_open() syscall returned with 95 (Operation not
supported). /bin/dmesg may provide additional information.
No hardware sampling interrup
12 matches
Mail list logo
