From: Peter Zijlstra <peterz@infradead.org>
To: Stephane Eranian <eranian@google.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu, gleb@redhat.com,
asharma@fb.com, vince@deater.net, wcohen@redhat.com
Subject: Re: perf_events: proposed fix for broken intr throttling (repost)
Date: Wed, 04 Jan 2012 23:49:56 +0100 [thread overview]
Message-ID: <1325717396.3084.12.camel@laptop> (raw)
In-Reply-To: <CABPqkBSR4a7PCyYxhE0kpepc3f0f6Rh6JU55_A3ubWYnN+G3iA@mail.gmail.com>
On Wed, 2012-01-04 at 21:33 +0000, Stephane Eranian wrote:
> > I don't think it needs that, I do dislike the unconditional iterate all
> > events thing though. Maybe we can set some per-cpu state indicating
> > someone got throttled (rare under normal operation -- you'd hope) and
> > only iterate to unthrottle when we find this set.
> >
> Could try that too.
>
> > I think the event scheduling resulting from migration will already
> > re-enable the event, avoiding the loss of unthrottle due to that..
> > although it would be good to verify that.
> >
> Yes, you're not dead forever, but still it is not acceptable as is.
Oh for sure, I didn't mean it like that. What I was getting at is a
counter getting throttled on one cpu, setting the per-cpu variable,
getting migrated and not getting unthrottled due to now living on
another cpu which doesn't have the per-cpu thing set.
If the scheduling resulting from the migration already unthrottles that
scenario can't happen.
next prev parent reply other threads:[~2012-01-04 22:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-04 14:39 perf_events: proposed fix for broken intr throttling (repost) Stephane Eranian
2012-01-04 21:24 ` Peter Zijlstra
2012-01-04 21:33 ` Stephane Eranian
2012-01-04 22:49 ` Peter Zijlstra [this message]
2012-01-04 23:02 ` Stephane Eranian
2012-01-05 13:08 ` Stephane Eranian
2012-01-05 13:19 ` Gleb Natapov
2012-01-05 13:31 ` Stephane Eranian
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=1325717396.3084.12.camel@laptop \
--to=peterz@infradead.org \
--cc=asharma@fb.com \
--cc=eranian@google.com \
--cc=gleb@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=vince@deater.net \
--cc=wcohen@redhat.com \
/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.