All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Kumar Gala <galak@kernel.crashing.org>
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras <paulus@samba.org>
Subject: Re: [PATCH] Emulate more instructions in software
Date: Thu, 19 Apr 2007 09:47:50 +0530	[thread overview]
Message-ID: <20070419041750.GA7687@in.ibm.com> (raw)
In-Reply-To: <1C486ED7-75EA-4DF7-820B-4ADDDC4CFA5E@kernel.crashing.org>

On Wed, Apr 18, 2007 at 11:25:55AM -0500, Kumar Gala wrote:
> 
> On Apr 18, 2007, at 11:23 AM, Kumar Gala wrote:
> 
> >
> >On Apr 18, 2007, at 2:13 AM, Ananth N Mavinakayanahalli wrote:
> >
> >>On Wed, Apr 18, 2007 at 01:11:00AM -0500, Kumar Gala wrote:
> >>>
> >>>On Apr 18, 2007, at 12:56 AM, Ananth N Mavinakayanahalli wrote:
> >>>
> >>>>Emulate a few more instructions in software - especially useful
> >>>>during
> >>>>singlestepping (xmon/kprobes).
> >>>>
> >>>>Instructions emulated with this patch are mfcr/mtcr rX, mfxer/mtxer
> >>>>rX,
> >>>>mflr/mtlr rX, mfctr/mtctr rX and mr rA,rB.
> >>>>
> >>>>
> >>>>Signed-off-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> >>>
> >>>When do we actually need to emulate any of these instructions?  I
> >>>don't see why single stepping would effect the ability to execute
> >>>these instructions.
> >>
> >>In cases when these instructions are kprobed, it'd be possible to
> >>eliminate the single step exception as we can emulate them.
> >>
> >>Most usecases of kprobes are at function entry and in most cases, the
> >>instruction at function entry is mflr r0, which can be emulated. So
> >>you
> >>can get rid of one exception and get a nice speedup too. My other
> >>patch
> >>did just this.
> >
> >Makes sense, how about wrapping the emulation of those instructions
> >in a #if defined(CONFIG_KPROBES) || defined(CONFIG_XMON).  Plus
> >adding a comment about these instructions just be emulated for
> >singlestepping performance and not because they are missing on some
> >platform.
> 
> Ignore this, I see this code is in lib/sstep.c not the main emulation  
> path.
> 
> >Also, do you really see that many mfxer/mtxer.  I'd expect them to be
> >rare.

Right. In fact, there were none in the .o files I checked. I put the
code for it for completeness wrt registers exposed by pt_regs.

Ananth

      reply	other threads:[~2007-04-19  4:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-18  5:56 [PATCH] Emulate more instructions in software Ananth N Mavinakayanahalli
2007-04-18  6:11 ` Kumar Gala
2007-04-18  7:13   ` Ananth N Mavinakayanahalli
2007-04-18 16:23     ` Kumar Gala
2007-04-18 16:25       ` Kumar Gala
2007-04-19  4:17         ` Ananth N Mavinakayanahalli [this message]

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=20070419041750.GA7687@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=galak@kernel.crashing.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=paulus@samba.org \
    /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.