Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1243966 > unrolled thread

Re: [PATCH] arm64: Increase the max granular size

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] arm64: Increase the max granular size Timur Tabi <timur@codeaurora.org> - 2015-10-10 19:40 +0200
    Re: [PATCH] arm64: Increase the max granular size Will Deacon <will.deacon@arm.com> - 2015-10-12 11:20 +0200

#1243966 — Re: [PATCH] arm64: Increase the max granular size

On Tue, Sep 22, 2015 at 12:59 PM, Robert Richter <rric@kernel.org> wrote:
>
> -#define L1_CACHE_SHIFT         6
> +#define L1_CACHE_SHIFT         7
>  #define L1_CACHE_BYTES         (1 << L1_CACHE_SHIFT)

Would it be better if this were a Kconfig option, like it is on ARM32?

http://lxr.free-electrons.com/source/arch/arm/include/asm/cache.h#L7

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1244515

On Sat, Oct 10, 2015 at 12:39:25PM -0500, Timur Tabi wrote:
> On Tue, Sep 22, 2015 at 12:59 PM, Robert Richter <rric@kernel.org> wrote:
> >
> > -#define L1_CACHE_SHIFT         6
> > +#define L1_CACHE_SHIFT         7
> >  #define L1_CACHE_BYTES         (1 << L1_CACHE_SHIFT)
> 
> Would it be better if this were a Kconfig option, like it is on ARM32?
> 
> http://lxr.free-electrons.com/source/arch/arm/include/asm/cache.h#L7

I don't think it adds anything, to be honest. We really want one kernel
that runs everywhere and we don't (yet) have the SoC variation that exists
on arch/arm/, so we may as well just keep it as big as it needs to be.
Of course, if we start to get significant divergence between the minimum
and maximum value and that in turn shows a non-trivial impact on kernel
size and/or performance, then we could consider a Kconfig option but at
that point we'd probably also need to consider whether there are alternative
ways of providing this information to the kernel.

If somebody really wants to change it for their particular kernel build,
modifying the #define isn't exactly rocket science.

Will
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web