All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Gleb Natapov <gleb@redhat.com>
Cc: linux-kernel@vger.kernel.org,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	mingo@elte.hu, rostedt <rostedt@goodmis.org>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH] perf, core: rate limit perf_sched_events jump_label patching
Date: Mon, 28 Nov 2011 12:14:45 -0500	[thread overview]
Message-ID: <20111128171445.GA2519@redhat.com> (raw)
In-Reply-To: <20111127155909.GO2557@redhat.com>

On Sun, Nov 27, 2011 at 05:59:09PM +0200, Gleb Natapov wrote:
> jump_lable patching is very expensive operation that involves pausing all
> cpus. The patching of perf_sched_events jump_label is easily controllable
> from userspace by unprivileged user. When user runs loop like this
> "while true; do perf stat -e cycles true; done" the performance of my
> test application that just increments a counter for one second drops by
> 4%. This is on a 16 cpu box with my test application using only one of
> them. An impact on a real server doing real work will be much worse.
> Performance of KVM PMU drops nearly 50% due to jump_lable for "perf
> record" since KVM PMU implementation creates and destroys perf event
> frequently.
> 
> This patch introduce the way to rate limit jump_label patching and uses
> it to fix above problem. I believe that as jump_label use will spread
> the problem will become more common and thus solving it in a generic
> code is appropriate. Also fixing it in a perf code will result in moving
> jump_label accounting logic to perf code with all the ifdefs in case
> of JUMP_LABEL=n kernel. With this patch all details are nicely hidden
> inside jump_label code.
> 

Looks good to me.

Acked-by: Jason Baron <jbaron@redhat.com>

Thanks,

-Jason

  parent reply	other threads:[~2011-11-28 17:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-27 15:59 [PATCH] perf, core: rate limit perf_sched_events jump_label patching Gleb Natapov
2011-11-28 11:18 ` Peter Zijlstra
2011-11-28 17:14 ` Jason Baron [this message]
2011-12-06  9:48 ` [tip:perf/core] perf, core: Rate " tip-bot for Gleb Natapov

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=20111128171445.GA2519@redhat.com \
    --to=jbaron@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=gleb@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.