All of lore.kernel.org
 help / color / mirror / Atom feed
From: Balbir Singh <bsingharora@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	paulus@samba.org, mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH] powerpc/mm: Use jump label to speed up radix_enabled check
Date: Wed, 27 Apr 2016 11:00:58 +1000	[thread overview]
Message-ID: <57200F4A.4070104@gmail.com> (raw)
In-Reply-To: <1461711943.3135.72.camel@kernel.crashing.org>



On 27/04/16 09:05, Benjamin Herrenschmidt wrote:
> On Wed, 2016-04-27 at 08:16 +1000, Balbir Singh wrote:
>>
>> On 27/04/16 07:05, Benjamin Herrenschmidt wrote:
>>>
>>> On Tue, 2016-04-26 at 21:54 +0530, Aneesh Kumar K.V wrote:
>>>>
>>>> This add generic mmu_feature_enabled() function that get patched
>>>> to take right code path based on the feature bit enabled. The
>>>> main
>>>> difference between the existing mmu_has_feature() function is the
>>>> hot patching using jump label framework.
>>>>
>>>> The implementation wraps around mmu_has_feature so that we can
>>>> use
>>>> this in early bootup code before we do the hotpatching.
>>> I'd rather we make mmu_has_feature() use jump labels and is the
>>> "main"
>>> API to be used by most code. If we have a need for a lower-level
>>> version for use by early boot code, call it __mmu_has_feature().
>>>
>>> This is more in-line with existing kernel practices and avoids
>>> having
>>> two APIs that somewhat look the same where it's not clear which one
>>> should be used.
>>>
>> Makes sense, but I suspect its a larger impact with loads of testing
>> required across platforms. Should this be done incrementally?
> 
> What kind of impact do you expect ?
> 

Just basic testing across CPUs with various mm features 
enabled/disabled. Just for sanity

Balbir

  reply	other threads:[~2016-04-27  1:01 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-26 16:24 [PATCH] powerpc/mm: Use jump label to speed up radix_enabled check Aneesh Kumar K.V
2016-04-26 21:05 ` Benjamin Herrenschmidt
2016-04-26 22:16   ` Balbir Singh
2016-04-26 23:05     ` Benjamin Herrenschmidt
2016-04-27  1:00       ` Balbir Singh [this message]
2016-04-27  1:46         ` Benjamin Herrenschmidt
2016-04-27  7:00           ` Aneesh Kumar K.V
2016-04-27  9:30             ` Aneesh Kumar K.V
2016-06-09  4:12             ` Benjamin Herrenschmidt
2016-06-09  6:00               ` Aneesh Kumar K.V
2016-06-09 15:58               ` Aneesh Kumar K.V
2016-06-10  4:16                 ` Michael Ellerman
2016-06-10  5:46                   ` 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=57200F4A.4070104@gmail.com \
    --to=bsingharora@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --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.