cache disabling

cache disabling

[Fabio Giovagnini]

Hi All,

If I set off the configuration of the cache am I sure no initialization of the 
cache is done and during all the working time of the CPU no cache is used?

Thanks a lot in advance


-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Fax. +39.051.082.14.49
Cell. +39.335.83.50.919
www.aurion-tech.com

Re: cache disabling

[Paul Mundt]

On Wed, Jan 12, 2011 at 07:04:20PM +0100, Fabio Giovagnini wrote:
> If I set off the configuration of the cache am I sure no initialization of the 
> cache is done and during all the working time of the CPU no cache is used?
> 
Yes, rather surprisingly, disabling the cache disables the cache.

Re: cache disabling

[Fabio Giovagnini]

Hi Paul thanks a lot for you patience with my stupid questions.
But it is not so surprising, because I verified in previuos kernels, that 
disabling all the options of the cache still the file cache-<cpu_type> was 
compiled and linked into the built-in.o file.
This has been the reason of my question.
Anyway if you confirm I'm really sure.

Thanks again vary much

On Thursday 13 January 2011 02:40:53 Paul Mundt wrote:
> On Wed, Jan 12, 2011 at 07:04:20PM +0100, Fabio Giovagnini wrote:
> > If I set off the configuration of the cache am I sure no initialization
> > of the cache is done and during all the working time of the CPU no cache
> > is used?
> 
> Yes, rather surprisingly, disabling the cache disables the cache.

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Fax. +39.051.082.14.49
Cell. +39.335.83.50.919
www.aurion-tech.com

Re: cache disabling

[Paul Mundt]

On Thu, Jan 13, 2011 at 06:28:44AM +0100, Fabio Giovagnini wrote:
> Hi Paul thanks a lot for you patience with my stupid questions.
> But it is not so surprising, because I verified in previuos kernels, that 
> disabling all the options of the cache still the file cache-<cpu_type> was 
> compiled and linked into the built-in.o file.
> This has been the reason of my question.
> Anyway if you confirm I'm really sure.
> 
I'm not sure what exactly linking has to do with anything, but a cursory
inspection of the code would have made it pretty apparent.

arch/sh/mm/cache.c shows:

void (*local_flush_cache_all)(void *args) = cache_noop;
void (*local_flush_cache_mm)(void *args) = cache_noop;
void (*local_flush_cache_dup_mm)(void *args) = cache_noop;
void (*local_flush_cache_page)(void *args) = cache_noop;
void (*local_flush_cache_range)(void *args) = cache_noop;
void (*local_flush_dcache_page)(void *args) = cache_noop;
void (*local_flush_icache_range)(void *args) = cache_noop;
void (*local_flush_icache_page)(void *args) = cache_noop;
void (*local_flush_cache_sigtramp)(void *args) = cache_noop;

....
void __init cpu_cache_init(void)
{
        unsigned int cache_disabled = 0;

#ifdef CCR
        cache_disabled = !(__raw_readl(CCR) & CCR_CACHE_ENABLE);
#endif

        /*
         * No flushing is necessary in the disabled cache case so we can
         * just keep the noop functions in local_flush_..() and __flush_..()
         */
        if (unlikely(cache_disabled))
                goto skip;

	...

skip:
        emit_cache_params();
}

I really shouldn't need to paste completely obvious code paths that have
already been documented to outline what happens in the case you describe.  Next
time you have a question like this, rather than opening up your mailer, how
about opening up your text editor and just looking at the code?

Contrary to popular belief, I don't generally comment code for my own benefit,
and it's becoming increasingly obvious that it's not of much benefit to people
who can't be bothered to read, either.

In the future, do not expect answers to questions you can easily answer
yourself.

Re: cache disabling

[Fabio Giovagnini]

I Apologize and I thank you again.
Regards



On Thursday 13 January 2011 07:50:25 Paul Mundt wrote:
> On Thu, Jan 13, 2011 at 06:28:44AM +0100, Fabio Giovagnini wrote:
> > Hi Paul thanks a lot for you patience with my stupid questions.
> > But it is not so surprising, because I verified in previuos kernels, that
> > disabling all the options of the cache still the file cache-<cpu_type>
> > was compiled and linked into the built-in.o file.
> > This has been the reason of my question.
> > Anyway if you confirm I'm really sure.
> 
> I'm not sure what exactly linking has to do with anything, but a cursory
> inspection of the code would have made it pretty apparent.
> 
> arch/sh/mm/cache.c shows:
> 
> void (*local_flush_cache_all)(void *args) = cache_noop;
> void (*local_flush_cache_mm)(void *args) = cache_noop;
> void (*local_flush_cache_dup_mm)(void *args) = cache_noop;
> void (*local_flush_cache_page)(void *args) = cache_noop;
> void (*local_flush_cache_range)(void *args) = cache_noop;
> void (*local_flush_dcache_page)(void *args) = cache_noop;
> void (*local_flush_icache_range)(void *args) = cache_noop;
> void (*local_flush_icache_page)(void *args) = cache_noop;
> void (*local_flush_cache_sigtramp)(void *args) = cache_noop;
> 
> ....
> void __init cpu_cache_init(void)
> {
>         unsigned int cache_disabled = 0;
> 
> #ifdef CCR
>         cache_disabled = !(__raw_readl(CCR) & CCR_CACHE_ENABLE);
> #endif
> 
>         /*
>          * No flushing is necessary in the disabled cache case so we can
>          * just keep the noop functions in local_flush_..() and
> __flush_..() */
>         if (unlikely(cache_disabled))
>                 goto skip;
> 
> 	...
> 
> skip:
>         emit_cache_params();
> }
> 
> I really shouldn't need to paste completely obvious code paths that have
> already been documented to outline what happens in the case you describe. 
> Next time you have a question like this, rather than opening up your
> mailer, how about opening up your text editor and just looking at the
> code?
> 
> Contrary to popular belief, I don't generally comment code for my own
> benefit, and it's becoming increasingly obvious that it's not of much
> benefit to people who can't be bothered to read, either.
> 
> In the future, do not expect answers to questions you can easily answer
> yourself.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Ing. Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
skype: aurion.giovagnini
Tel. +39.051.594.78.24
Fax. +39.051.082.14.49
Cell. +39.335.83.50.919
www.aurion-tech.com