linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
Cc: benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au,
	linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH for-4.8 V2 00/10] Use jump label for cpu/mmu_has_feature
Date: Mon, 25 Jul 2016 16:37:11 +1000	[thread overview]
Message-ID: <20160725163711.648355ee@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <87shuykzdd.fsf@skywalker.in.ibm.com>

On Mon, 25 Jul 2016 11:55:50 +0530
"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Sat, 23 Jul 2016 14:42:33 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >  
> >> Changes from V1:
> >> * Update "powerpc/mm: Convert early cpu/mmu feature check to use
> >> the new helpers" based on resend code changes in this area.
> >> 
> >> We now do feature fixup early and hence we can reduce the usage of
> >>  __cpu/__mmu_has_feature.  
> >
> > Is there a particular reason for for-4.8?
> >
> > I've only just started following this development so it might be
> > obvious, but if you could add some small justifications for why
> > a patch or series is done, it would be of great help to me.  
> 
> The goal is to reduce the impact of radix series on existing MMU
> function. With radix series, we do
> 
> if (radix_enabled())
>         radix_function()
> else
>         hash_function()
> 
> We did try to reduce the impact in most code path like linux page
> table accessors by moving linux pte bits around to match the
> radix/hardware requirements. But we still have other code paths where
> we do the above conditional.
> 
> Now for-4.8 is mainly because, I was trying to make sure 4.8 release
> will have a good performing radix/hash implementation which distros
> can base their kernel on. This series was posted to external list
> multiple times and I didn't receive many objections to the series.
> Hence I was thinking it to be a good idea to get it upstream by 4.8.

Thanks, I was just curious. I don't have an objection.

It would be a bigger change, but it might be nice to do alternate
patching for some of these, so we could even avoid the branch for
the radix case in some of the critical functions. That's something
for later though.

Thanks,
Nick

      reply	other threads:[~2016-07-25  6:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-23  9:12 [PATCH for-4.8 V2 00/10] Use jump label for cpu/mmu_has_feature Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 01/10] powerpc/mm: Add __cpu/__mmu_has_feature Aneesh Kumar K.V
2016-07-25  5:26   ` Nicholas Piggin
2016-07-23  9:12 ` [PATCH for-4.8 V2 02/10] powerpc/mm: Convert early cpu/mmu feature check to use the new helpers Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 03/10] powerpc/mm/radix: Add radix_set_pte to use in early init Aneesh Kumar K.V
2016-07-25  6:23   ` Nicholas Piggin
2016-07-25  8:33     ` Michael Ellerman
2016-07-25  8:36   ` Michael Ellerman
2016-07-25  8:56     ` Nicholas Piggin
2016-07-23  9:12 ` [PATCH for-4.8 V2 04/10] jump_label: make it possible for the archs to invoke jump_label_init() much earlier Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 05/10] powerpc: Call jump_label_init early Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 06/10] powerpc: kill mfvtb() Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 07/10] powerpc: move the cpu_has_feature to a separate file Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 08/10] powerpc: use the jump label for cpu_has_feature Aneesh Kumar K.V
2016-07-25  6:28   ` Nicholas Piggin
2016-07-25 11:30     ` Kevin Hao
2016-07-23  9:12 ` [PATCH for-4.8 V2 09/10] powerpc: use jump label for mmu_has_feature Aneesh Kumar K.V
2016-07-23  9:12 ` [PATCH for-4.8 V2 10/10] powerpc/mm: Catch the usage of cpu/mmu_has_feature before jump label init Aneesh Kumar K.V
2016-07-25  5:22 ` [PATCH for-4.8 V2 00/10] Use jump label for cpu/mmu_has_feature Nicholas Piggin
2016-07-25  6:25   ` Aneesh Kumar K.V
2016-07-25  6:37     ` Nicholas Piggin [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=20160725163711.648355ee@roar.ozlabs.ibm.com \
    --to=npiggin@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 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).