public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Wang Nan <wangnan0@huawei.com>
To: "Jon Medhurst (Tixy)" <tixy@linaro.org>
Cc: <masami.hiramatsu.pt@hitachi.com>, <linux@arm.linux.org.uk>,
	<will.deacon@arm.com>, <taras.kondratiuk@linaro.org>,
	<ben.dooks@codethink.co.uk>, <cl@linux.com>, <rabin@rab.in>,
	<davem@davemloft.net>, <lizefan@huawei.com>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v10 2/2] ARM: kprobes: enable OPTPROBES for ARM 32
Date: Sat, 29 Nov 2014 09:28:24 +0800	[thread overview]
Message-ID: <54792138.2060008@huawei.com> (raw)
In-Reply-To: <1417099007.2041.6.camel@linaro.org>

On 2014/11/27 22:36, Jon Medhurst (Tixy) wrote:
> On Fri, 2014-11-21 at 14:35 +0800, Wang Nan wrote:
>> This patch introduce kprobeopt for ARM 32.
> 
> If I've understood things correctly, this is a feature which inserts
> probes by using a branch instruction to some trampoline code rather than
> using an undefined instruction as a breakpoint. That way we avoid the
> overhead of processing the exception and it is this performance
> improvement which is the main/only reason for implementing it?
> 
> If so, I though it good to see what kind of improvement we get by
> running the micro benchmarks in the kprobes test code. On an A7/A15
> big.LITTLE vexpress board the approximate figures I get are 0.3us for
> optimised probe, 1us for un-optimised, so a three times performance
> improvement. This is with an empty probe pre-handler and no post
> handler, so with a more realistic usecase, the relative improvement we
> get from optimisation would be less.
> 
> I thought it good to see what sort of benefits this code achieves,
> especially as it could grow quite complex over time, and the cost of
> that versus the benefit should be considered.
> 
> 

Thanks for your comments and your comprehensive testing.

In fact I have got even worst performance result on my hardware platform.
However, by utilizing previous introduced checker code to check instructions
in detail, I believe we can eliminate most of the emulation/simulation works
so the cost can be reduced.

Futhermore, kprobeopt can avoid exceptions, which have at least 2 advantanges:

1. Make things simpler. Although exception processing is fast in real hardware,
   it still need more state changing and processing than a branch instruction,
   which may cause unexcepted problems.

2. Branch instructions can be used in more cases than exception. For example,
   at very early stage of kernel booting when exception vector is
   not installed, and at kernel panic processing.




  parent reply	other threads:[~2014-11-29  1:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21  6:35 [PATCH v10 0/2] ARM: kprobes: enable OPTPROBES for ARM32 Wang Nan
2014-11-21  6:35 ` [PATCH v10 1/2] kprobes: Pass the original kprobe for preparing optimized kprobe Wang Nan
2014-11-21  6:35 ` [PATCH v10 2/2] ARM: kprobes: enable OPTPROBES for ARM 32 Wang Nan
2014-11-27 14:36   ` Jon Medhurst (Tixy)
2014-11-28  3:12     ` Masami Hiramatsu
2014-11-28 10:08       ` Jon Medhurst (Tixy)
2014-11-28 10:43         ` Masami Hiramatsu
2014-11-28 11:13         ` Russell King - ARM Linux
2014-11-28 11:17           ` Jon Medhurst (Tixy)
2014-11-29  1:28     ` Wang Nan [this message]
2014-12-01  1:29     ` Wang Nan
2014-12-01  8:59       ` Wang Nan

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=54792138.2060008@huawei.com \
    --to=wangnan0@huawei.com \
    --cc=ben.dooks@codethink.co.uk \
    --cc=cl@linux.com \
    --cc=davem@davemloft.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lizefan@huawei.com \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=rabin@rab.in \
    --cc=taras.kondratiuk@linaro.org \
    --cc=tixy@linaro.org \
    --cc=will.deacon@arm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox