linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Anton Blanchard <anton@samba.org>
Cc: Michael Neuling <mikey@neuling.org>,
	paulus@samba.org, sukadev@linux.vnet.ibm.com,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX
Date: Fri, 09 Dec 2011 06:40:15 +1100	[thread overview]
Message-ID: <1323373215.12793.38.camel@pasglop> (raw)
In-Reply-To: <20111208170450.22247a4b@kryten>

On Thu, 2011-12-08 at 17:04 +1100, Anton Blanchard wrote:
> Hi,
> 
> > I hate the idea of having a POWER7 FTR bit.  Every loon will (and has
> > tried to in the past) attach every POWER7 related thing to it, rather
> > than thinking about what the feature really is for.  
> > 
> > What about other processors which could also benefit from this copy
> > loop?  Turning on CPU_FTR_POWER7 for them is gonna look a bit silly.
> 
> As we discussed online, we could call it CPU_FTR_VMX_COPY and start
> thinking about a better way to solve the CPU feature bit mess.
> 
> One idea would be to have a structure of function pointers for each
> CPU that gets runtime patched into the right places, similar to how we
> do some of the MMU fixups.

Or the vdso... we have a table of some sort which is used to patch
symbols.

But it's keyed off cpu features.

I'm reluctant to adding another table of PVRs, it needs to deal with the
pseudo-PVRs from pHyp, and things will get out of sync.

CPU features are the way to go, tho we can use them to key off a branch
patching mechanism if we want to. It's easy to add new bitmasks for
in-kernel features at least (it's the user features which are more nasty
but they are a separate thing).

So if we have to we can split cpu feature into another separate mask
like I did for mmu features with the same macros etc... For example, the
debug features could be moved out, or whatever.

Cheers,
Ben.
 

  parent reply	other threads:[~2011-12-08 19:40 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-08  5:02 [PATCH] powerpc: POWER7 optimised copy_to_user/copy_from_user using VMX Anton Blanchard
2011-12-08  5:44 ` Kumar Gala
2011-12-08  5:54   ` Michael Neuling
2011-12-08  6:04     ` Anton Blanchard
2011-12-08 13:31       ` Segher Boessenkool
2011-12-08 14:02         ` David Laight
2011-12-08 14:12           ` Segher Boessenkool
2011-12-08 19:40       ` Benjamin Herrenschmidt [this message]
2011-12-08  6:11     ` Anton Blanchard
2011-12-19  3:00       ` Benjamin Herrenschmidt
2011-12-19  3:19         ` Benjamin Herrenschmidt

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=1323373215.12793.38.camel@pasglop \
    --to=benh@kernel.crashing.org \
    --cc=anton@samba.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mikey@neuling.org \
    --cc=paulus@samba.org \
    --cc=sukadev@linux.vnet.ibm.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;
as well as URLs for NNTP newsgroup(s).