All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: [PATCH] perf_event: fix loss of notification with multi-event sampling
Date: Tue, 22 Nov 2011 14:29:19 +0100	[thread overview]
Message-ID: <1321968559.14799.2.camel@twins> (raw)
In-Reply-To: <CABPqkBT-ZPZC2Ku6NjyMygWUU+kMr3h9FCdKTAjvhR6ywFmNqw@mail.gmail.com>

On Tue, 2011-11-22 at 14:15 +0100, Stephane Eranian wrote:

> > Ah, could it be a race of poll()/wakeup() vs perf_event_set_output() ?
> >
> Are you saying that by dropping event->waitq in favor of event->rb->waitq
> we make this problem disappear due to rcu protections?

Well, except..

> Poll_wait() is a blocking call. It may wait on a stale waitq.  But that problem
> was probably already there. I am not clear as to what to do about that.
> in perf_set_output() you would need to wakeup from poll_wait() and then
> go back in with the new waitq.

Right, the whole blocking thing is a problem, and the whole poll()
interface always makes my head hurt.

If there was a go-sleep and wake-up side to poll we could do
ring_buffer_get()/put() and fix this problem, but I'm not finding a way
to make that happen quite yet.

> Similarly, I am not clear as to what happens when you close an event for
> which you have  a waiter in poll_wait(). I assume you wakeup from it.
> But I don't see where that's implemented.

Good point, yes we should do that.

  reply	other threads:[~2011-11-22 13:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-16 14:53 [PATCH] perf_event: fix loss of notification with multi-event sampling Stephane Eranian
2011-11-22 10:40 ` Peter Zijlstra
2011-11-22 13:15   ` Stephane Eranian
2011-11-22 13:29     ` Peter Zijlstra [this message]
2011-11-22 14:13       ` Stephane Eranian
2011-11-22 14:28         ` Stephane Eranian
2011-11-22 21:15           ` Peter Zijlstra
2011-11-23  9:30       ` Stephane Eranian
2011-11-23 10:06         ` Peter Zijlstra
2011-11-23 10:10           ` Stephane Eranian
2011-11-23 10:36             ` Peter Zijlstra

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=1321968559.14799.2.camel@twins \
    --to=peterz@infradead.org \
    --cc=eranian@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.