Sometimes we want to know an accurate number of samples even if it's
lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
might be shared with other events. So it's hard to know per-event
lost count.
Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
retrieve it from userspace.
Signed-off-by: Namhyung Kim <[email protected]>
---
include/linux/perf_event.h | 2 ++
include/uapi/linux/perf_event.h | 1 +
kernel/events/core.c | 9 +++++++++
kernel/events/ring_buffer.c | 5 ++++-
4 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f5a6a2f069ed..44d72079c77a 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -756,6 +756,8 @@ struct perf_event {
struct pid_namespace *ns;
u64 id;
+ atomic_t lost_samples;
+
u64 (*clock)(void);
perf_overflow_handler_t overflow_handler;
void *overflow_handler_context;
diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
index bf8143505c49..24397799127d 100644
--- a/include/uapi/linux/perf_event.h
+++ b/include/uapi/linux/perf_event.h
@@ -505,6 +505,7 @@ struct perf_event_query_bpf {
#define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
#define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
#define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
+#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
enum perf_event_ioc_flags {
PERF_IOC_FLAG_GROUP = 1U << 0,
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 0e125ae2fa92..a4d6736b6594 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5664,6 +5664,15 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
return perf_event_modify_attr(event, &new_attr);
}
+
+ case PERF_EVENT_IOC_LOST_SAMPLES: {
+ u64 lost = atomic_read(&event->lost_samples);
+
+ if (copy_to_user((void __user *)arg, &lost, sizeof(lost)))
+ return -EFAULT;
+ return 0;
+ }
+
default:
return -ENOTTY;
}
diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
index 52868716ec35..06d7dacb05da 100644
--- a/kernel/events/ring_buffer.c
+++ b/kernel/events/ring_buffer.c
@@ -172,8 +172,10 @@ __perf_output_begin(struct perf_output_handle *handle,
goto out;
if (unlikely(rb->paused)) {
- if (rb->nr_pages)
+ if (rb->nr_pages) {
local_inc(&rb->lost);
+ atomic_inc(&event->lost_samples);
+ }
goto out;
}
@@ -254,6 +256,7 @@ __perf_output_begin(struct perf_output_handle *handle,
fail:
local_inc(&rb->lost);
+ atomic_inc(&event->lost_samples);
perf_output_put_handle(handle);
out:
rcu_read_unlock();
--
2.32.0.605.g8dce9f2422-goog
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index f5a6a2f069ed..44d72079c77a 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -756,6 +756,8 @@ struct perf_event {
> struct pid_namespace *ns;
> u64 id;
>
> + atomic_t lost_samples;
Would rather use atomic64_t. atomic_t might wrap too quickly.
But it might be better to put it somewhere where you already have a lock
on the event, then you wouldn't need an atomic.
-Andi
On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> Sometimes we want to know an accurate number of samples even if it's
> lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> might be shared with other events. So it's hard to know per-event
> lost count.
>
> Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> retrieve it from userspace.
>
> Signed-off-by: Namhyung Kim <[email protected]>
> ---
> include/linux/perf_event.h | 2 ++
> include/uapi/linux/perf_event.h | 1 +
> kernel/events/core.c | 9 +++++++++
> kernel/events/ring_buffer.c | 5 ++++-
> 4 files changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index f5a6a2f069ed..44d72079c77a 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -756,6 +756,8 @@ struct perf_event {
> struct pid_namespace *ns;
> u64 id;
>
> + atomic_t lost_samples;
> +
> u64 (*clock)(void);
> perf_overflow_handler_t overflow_handler;
> void *overflow_handler_context;
> diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> index bf8143505c49..24397799127d 100644
> --- a/include/uapi/linux/perf_event.h
> +++ b/include/uapi/linux/perf_event.h
> @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
would it be better to use the read syscall for that?
https://lore.kernel.org/lkml/[email protected]/
that patchset ended up on me not having a way to reproduce the
issue you guys wanted the fix for ;-) the lost count is there
as well
jirka
>
> enum perf_event_ioc_flags {
> PERF_IOC_FLAG_GROUP = 1U << 0,
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 0e125ae2fa92..a4d6736b6594 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -5664,6 +5664,15 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
>
> return perf_event_modify_attr(event, &new_attr);
> }
> +
> + case PERF_EVENT_IOC_LOST_SAMPLES: {
> + u64 lost = atomic_read(&event->lost_samples);
> +
> + if (copy_to_user((void __user *)arg, &lost, sizeof(lost)))
> + return -EFAULT;
> + return 0;
> + }
> +
> default:
> return -ENOTTY;
> }
> diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> index 52868716ec35..06d7dacb05da 100644
> --- a/kernel/events/ring_buffer.c
> +++ b/kernel/events/ring_buffer.c
> @@ -172,8 +172,10 @@ __perf_output_begin(struct perf_output_handle *handle,
> goto out;
>
> if (unlikely(rb->paused)) {
> - if (rb->nr_pages)
> + if (rb->nr_pages) {
> local_inc(&rb->lost);
> + atomic_inc(&event->lost_samples);
> + }
> goto out;
> }
>
> @@ -254,6 +256,7 @@ __perf_output_begin(struct perf_output_handle *handle,
>
> fail:
> local_inc(&rb->lost);
> + atomic_inc(&event->lost_samples);
> perf_output_put_handle(handle);
> out:
> rcu_read_unlock();
> --
> 2.32.0.605.g8dce9f2422-goog
>
On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
>
> On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > Sometimes we want to know an accurate number of samples even if it's
> > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > might be shared with other events. So it's hard to know per-event
> > lost count.
> >
> > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > retrieve it from userspace.
> >
> > Signed-off-by: Namhyung Kim <[email protected]>
> > ---
> > include/linux/perf_event.h | 2 ++
> > include/uapi/linux/perf_event.h | 1 +
> > kernel/events/core.c | 9 +++++++++
> > kernel/events/ring_buffer.c | 5 ++++-
> > 4 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index f5a6a2f069ed..44d72079c77a 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -756,6 +756,8 @@ struct perf_event {
> > struct pid_namespace *ns;
> > u64 id;
> >
> > + atomic_t lost_samples;
> > +
> > u64 (*clock)(void);
> > perf_overflow_handler_t overflow_handler;
> > void *overflow_handler_context;
> > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > index bf8143505c49..24397799127d 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
>
> would it be better to use the read syscall for that?
> https://lore.kernel.org/lkml/[email protected]/
>
> that patchset ended up on me not having a way to reproduce the
> issue you guys wanted the fix for ;-) the lost count is there
> as well
>
Does the read format approach succeed even when the event is in error state?
> jirka
>
> >
> > enum perf_event_ioc_flags {
> > PERF_IOC_FLAG_GROUP = 1U << 0,
> > diff --git a/kernel/events/core.c b/kernel/events/core.c
> > index 0e125ae2fa92..a4d6736b6594 100644
> > --- a/kernel/events/core.c
> > +++ b/kernel/events/core.c
> > @@ -5664,6 +5664,15 @@ static long _perf_ioctl(struct perf_event *event, unsigned int cmd, unsigned lon
> >
> > return perf_event_modify_attr(event, &new_attr);
> > }
> > +
> > + case PERF_EVENT_IOC_LOST_SAMPLES: {
> > + u64 lost = atomic_read(&event->lost_samples);
> > +
> > + if (copy_to_user((void __user *)arg, &lost, sizeof(lost)))
> > + return -EFAULT;
> > + return 0;
> > + }
> > +
> > default:
> > return -ENOTTY;
> > }
> > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c
> > index 52868716ec35..06d7dacb05da 100644
> > --- a/kernel/events/ring_buffer.c
> > +++ b/kernel/events/ring_buffer.c
> > @@ -172,8 +172,10 @@ __perf_output_begin(struct perf_output_handle *handle,
> > goto out;
> >
> > if (unlikely(rb->paused)) {
> > - if (rb->nr_pages)
> > + if (rb->nr_pages) {
> > local_inc(&rb->lost);
> > + atomic_inc(&event->lost_samples);
> > + }
> > goto out;
> > }
> >
> > @@ -254,6 +256,7 @@ __perf_output_begin(struct perf_output_handle *handle,
> >
> > fail:
> > local_inc(&rb->lost);
> > + atomic_inc(&event->lost_samples);
> > perf_output_put_handle(handle);
> > out:
> > rcu_read_unlock();
> > --
> > 2.32.0.605.g8dce9f2422-goog
> >
>
On Wed, Aug 11, 2021 at 12:33:38PM -0700, Stephane Eranian wrote:
> On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
> >
> > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > Sometimes we want to know an accurate number of samples even if it's
> > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > might be shared with other events. So it's hard to know per-event
> > > lost count.
> > >
> > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > retrieve it from userspace.
> > >
> > > Signed-off-by: Namhyung Kim <[email protected]>
> > > ---
> > > include/linux/perf_event.h | 2 ++
> > > include/uapi/linux/perf_event.h | 1 +
> > > kernel/events/core.c | 9 +++++++++
> > > kernel/events/ring_buffer.c | 5 ++++-
> > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index f5a6a2f069ed..44d72079c77a 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -756,6 +756,8 @@ struct perf_event {
> > > struct pid_namespace *ns;
> > > u64 id;
> > >
> > > + atomic_t lost_samples;
> > > +
> > > u64 (*clock)(void);
> > > perf_overflow_handler_t overflow_handler;
> > > void *overflow_handler_context;
> > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > index bf8143505c49..24397799127d 100644
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
> > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> >
> > would it be better to use the read syscall for that?
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > that patchset ended up on me not having a way to reproduce the
> > issue you guys wanted the fix for ;-) the lost count is there
> > as well
> >
> Does the read format approach succeed even when the event is in error state?
nope..
/*
* Return end-of-file for a read on an event that is in
* error state (i.e. because it was pinned but it couldn't be
* scheduled on to the CPU at some point).
*/
if (event->state == PERF_EVENT_STATE_ERROR)
return 0;
jirka
Hi Jiri,
On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
>
> On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > Sometimes we want to know an accurate number of samples even if it's
> > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > might be shared with other events. So it's hard to know per-event
> > lost count.
> >
> > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > retrieve it from userspace.
> >
> > Signed-off-by: Namhyung Kim <[email protected]>
> > ---
> > include/linux/perf_event.h | 2 ++
> > include/uapi/linux/perf_event.h | 1 +
> > kernel/events/core.c | 9 +++++++++
> > kernel/events/ring_buffer.c | 5 ++++-
> > 4 files changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > index f5a6a2f069ed..44d72079c77a 100644
> > --- a/include/linux/perf_event.h
> > +++ b/include/linux/perf_event.h
> > @@ -756,6 +756,8 @@ struct perf_event {
> > struct pid_namespace *ns;
> > u64 id;
> >
> > + atomic_t lost_samples;
> > +
> > u64 (*clock)(void);
> > perf_overflow_handler_t overflow_handler;
> > void *overflow_handler_context;
> > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > index bf8143505c49..24397799127d 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
>
> would it be better to use the read syscall for that?
> https://lore.kernel.org/lkml/[email protected]/
>
> that patchset ended up on me not having a way to reproduce the
> issue you guys wanted the fix for ;-) the lost count is there
> as well
Oh, right... I forgot about that, sorry.
But I think the lost count is not collected accurately.
Peter, what do you think about the interface (read vs ioctl)?
Thanks,
Namhyung
On Wed, Aug 11, 2021 at 12:57 PM Jiri Olsa <[email protected]> wrote:
>
> On Wed, Aug 11, 2021 at 12:33:38PM -0700, Stephane Eranian wrote:
> > On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
> > >
> > > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > > Sometimes we want to know an accurate number of samples even if it's
> > > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > > might be shared with other events. So it's hard to know per-event
> > > > lost count.
> > > >
> > > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > > retrieve it from userspace.
> > > >
> > > > Signed-off-by: Namhyung Kim <[email protected]>
> > > > ---
> > > > include/linux/perf_event.h | 2 ++
> > > > include/uapi/linux/perf_event.h | 1 +
> > > > kernel/events/core.c | 9 +++++++++
> > > > kernel/events/ring_buffer.c | 5 ++++-
> > > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > index f5a6a2f069ed..44d72079c77a 100644
> > > > --- a/include/linux/perf_event.h
> > > > +++ b/include/linux/perf_event.h
> > > > @@ -756,6 +756,8 @@ struct perf_event {
> > > > struct pid_namespace *ns;
> > > > u64 id;
> > > >
> > > > + atomic_t lost_samples;
> > > > +
> > > > u64 (*clock)(void);
> > > > perf_overflow_handler_t overflow_handler;
> > > > void *overflow_handler_context;
> > > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > > index bf8143505c49..24397799127d 100644
> > > > --- a/include/uapi/linux/perf_event.h
> > > > +++ b/include/uapi/linux/perf_event.h
> > > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> > >
> > > would it be better to use the read syscall for that?
> > > https://lore.kernel.org/lkml/[email protected]/
> > >
> > > that patchset ended up on me not having a way to reproduce the
> > > issue you guys wanted the fix for ;-) the lost count is there
> > > as well
> > >
> > Does the read format approach succeed even when the event is in error state?
>
> nope..
>
> /*
> * Return end-of-file for a read on an event that is in
> * error state (i.e. because it was pinned but it couldn't be
> * scheduled on to the CPU at some point).
> */
> if (event->state == PERF_EVENT_STATE_ERROR)
> return 0;
>
By the way, it'd be nice if the kernel would provide a way for
better error reporting. There are many cases return -EINVAL
and it's hard to know what's the problem exactly.
Thanks,
Namhyung
On Wed, Aug 11, 2021 at 1:57 PM Namhyung Kim <[email protected]> wrote:
>
> On Wed, Aug 11, 2021 at 12:57 PM Jiri Olsa <[email protected]> wrote:
> >
> > On Wed, Aug 11, 2021 at 12:33:38PM -0700, Stephane Eranian wrote:
> > > On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
> > > >
> > > > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > > > Sometimes we want to know an accurate number of samples even if it's
> > > > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > > > might be shared with other events. So it's hard to know per-event
> > > > > lost count.
> > > > >
> > > > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > > > retrieve it from userspace.
> > > > >
> > > > > Signed-off-by: Namhyung Kim <[email protected]>
> > > > > ---
> > > > > include/linux/perf_event.h | 2 ++
> > > > > include/uapi/linux/perf_event.h | 1 +
> > > > > kernel/events/core.c | 9 +++++++++
> > > > > kernel/events/ring_buffer.c | 5 ++++-
> > > > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > > index f5a6a2f069ed..44d72079c77a 100644
> > > > > --- a/include/linux/perf_event.h
> > > > > +++ b/include/linux/perf_event.h
> > > > > @@ -756,6 +756,8 @@ struct perf_event {
> > > > > struct pid_namespace *ns;
> > > > > u64 id;
> > > > >
> > > > > + atomic_t lost_samples;
> > > > > +
> > > > > u64 (*clock)(void);
> > > > > perf_overflow_handler_t overflow_handler;
> > > > > void *overflow_handler_context;
> > > > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > > > index bf8143505c49..24397799127d 100644
> > > > > --- a/include/uapi/linux/perf_event.h
> > > > > +++ b/include/uapi/linux/perf_event.h
> > > > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> > > >
> > > > would it be better to use the read syscall for that?
> > > > https://lore.kernel.org/lkml/[email protected]/
> > > >
> > > > that patchset ended up on me not having a way to reproduce the
> > > > issue you guys wanted the fix for ;-) the lost count is there
> > > > as well
> > > >
> > > Does the read format approach succeed even when the event is in error state?
> >
> > nope..
> >
> > /*
> > * Return end-of-file for a read on an event that is in
> > * error state (i.e. because it was pinned but it couldn't be
> > * scheduled on to the CPU at some point).
> > */
> > if (event->state == PERF_EVENT_STATE_ERROR)
> > return 0;
> >
>
> By the way, it'd be nice if the kernel would provide a way for
> better error reporting. There are many cases return -EINVAL
> and it's hard to know what's the problem exactly.
>
+1. If the kernel has more precise error reporting, then the tool
could be more helpful in its error reporting and not try to guess with
heuristics.
On Wed, Aug 11, 2021 at 01:54:09PM -0700, Namhyung Kim wrote:
> Hi Jiri,
>
> On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
> >
> > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > Sometimes we want to know an accurate number of samples even if it's
> > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > might be shared with other events. So it's hard to know per-event
> > > lost count.
> > >
> > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > retrieve it from userspace.
> > >
> > > Signed-off-by: Namhyung Kim <[email protected]>
> > > ---
> > > include/linux/perf_event.h | 2 ++
> > > include/uapi/linux/perf_event.h | 1 +
> > > kernel/events/core.c | 9 +++++++++
> > > kernel/events/ring_buffer.c | 5 ++++-
> > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > index f5a6a2f069ed..44d72079c77a 100644
> > > --- a/include/linux/perf_event.h
> > > +++ b/include/linux/perf_event.h
> > > @@ -756,6 +756,8 @@ struct perf_event {
> > > struct pid_namespace *ns;
> > > u64 id;
> > >
> > > + atomic_t lost_samples;
> > > +
> > > u64 (*clock)(void);
> > > perf_overflow_handler_t overflow_handler;
> > > void *overflow_handler_context;
> > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > index bf8143505c49..24397799127d 100644
> > > --- a/include/uapi/linux/perf_event.h
> > > +++ b/include/uapi/linux/perf_event.h
> > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> >
> > would it be better to use the read syscall for that?
> > https://lore.kernel.org/lkml/[email protected]/
> >
> > that patchset ended up on me not having a way to reproduce the
> > issue you guys wanted the fix for ;-) the lost count is there
> > as well
>
> Oh, right... I forgot about that, sorry.
> But I think the lost count is not collected accurately.
>
> Peter, what do you think about the interface (read vs ioctl)?
I think I'm the one that suggested PERF_FORMAT_LOST at the time :-)
Hi Peter,
On Tue, Aug 24, 2021 at 7:05 AM Peter Zijlstra <[email protected]> wrote:
>
> On Wed, Aug 11, 2021 at 01:54:09PM -0700, Namhyung Kim wrote:
> > Hi Jiri,
> >
> > On Wed, Aug 11, 2021 at 8:04 AM Jiri Olsa <[email protected]> wrote:
> > >
> > > On Tue, Aug 10, 2021 at 11:21:35PM -0700, Namhyung Kim wrote:
> > > > Sometimes we want to know an accurate number of samples even if it's
> > > > lost. Currenlty PERF_RECORD_LOST is generated for a ring-buffer which
> > > > might be shared with other events. So it's hard to know per-event
> > > > lost count.
> > > >
> > > > Add event->lost_samples field and PERF_EVENT_IOC_LOST_SAMPLES to
> > > > retrieve it from userspace.
> > > >
> > > > Signed-off-by: Namhyung Kim <[email protected]>
> > > > ---
> > > > include/linux/perf_event.h | 2 ++
> > > > include/uapi/linux/perf_event.h | 1 +
> > > > kernel/events/core.c | 9 +++++++++
> > > > kernel/events/ring_buffer.c | 5 ++++-
> > > > 4 files changed, 16 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> > > > index f5a6a2f069ed..44d72079c77a 100644
> > > > --- a/include/linux/perf_event.h
> > > > +++ b/include/linux/perf_event.h
> > > > @@ -756,6 +756,8 @@ struct perf_event {
> > > > struct pid_namespace *ns;
> > > > u64 id;
> > > >
> > > > + atomic_t lost_samples;
> > > > +
> > > > u64 (*clock)(void);
> > > > perf_overflow_handler_t overflow_handler;
> > > > void *overflow_handler_context;
> > > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > > > index bf8143505c49..24397799127d 100644
> > > > --- a/include/uapi/linux/perf_event.h
> > > > +++ b/include/uapi/linux/perf_event.h
> > > > @@ -505,6 +505,7 @@ struct perf_event_query_bpf {
> > > > #define PERF_EVENT_IOC_PAUSE_OUTPUT _IOW('$', 9, __u32)
> > > > #define PERF_EVENT_IOC_QUERY_BPF _IOWR('$', 10, struct perf_event_query_bpf *)
> > > > #define PERF_EVENT_IOC_MODIFY_ATTRIBUTES _IOW('$', 11, struct perf_event_attr *)
> > > > +#define PERF_EVENT_IOC_LOST_SAMPLES _IOR('$', 12, __u64 *)
> > >
> > > would it be better to use the read syscall for that?
> > > https://lore.kernel.org/lkml/[email protected]/
> > >
> > > that patchset ended up on me not having a way to reproduce the
> > > issue you guys wanted the fix for ;-) the lost count is there
> > > as well
> >
> > Oh, right... I forgot about that, sorry.
> > But I think the lost count is not collected accurately.
> >
> > Peter, what do you think about the interface (read vs ioctl)?
>
> I think I'm the one that suggested PERF_FORMAT_LOST at the time :-)
Ah, ok. I'm fine with the read format then.
Thanks,
Namhyung