[PATCH for-4.8 V2 00/10] Use jump label for cpu/mmu_has_feature

Nicholas Piggin npiggin at gmail.com
Mon Jul 25 16:37:11 AEST 2016


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

> Nicholas Piggin <npiggin at gmail.com> writes:
> 
> > On Sat, 23 Jul 2016 14:42:33 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar at 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


More information about the Linuxppc-dev mailing list