...cache dimensioning ;-)

...cache dimensioning ;-)

[Emmanuel Michon]

Hi,

I'm still in the process of choosing the best configurable parameters of
a hardware design based on 4KEc

As far as I understand, excepted alpha platforms, 4KByte pages are the
de facto standard [I assume linux developers are reasonable so changing
the page size to 8KB is not going to be a nightmare...]

Since the mips cache is virtually indexed but physically tagged, I see
two problems when the size of a cache way exceeds the size of a page:

- virtual aliasing. Can only happen on R/W pages (data cache) and only
when two different virtual addresses map the same physical page. An
example of this is: two processes sharing a memory area; should I
consider this is taken into account by linux already?

- I was told the software exception handlers for tlb are much less
efficient when cacheway > pagesize, forcing to flush too often. Is this
true? What is, in practice, the ratio of instruction pages and data
pages in a tlb?

If I consider a platform like Toshiba TX39 which has d-cache four ways
with total 32KBytes, it must already have the problems above. I'd like
to get some more clues though...

Thanks a lot,

Sincerely yours,

E.M.

Re: ...cache dimensioning ;-)

[Ralf Baechle]

On Fri, Sep 10, 2004 at 12:15:58PM +0200, Emmanuel Michon wrote:

> I'm still in the process of choosing the best configurable parameters of
> a hardware design based on 4KEc

Simply answer:

Linux is most happy if size_per_cache =< PAGE_SIZE * number_of_ways.

> As far as I understand, excepted alpha platforms, 4KByte pages are the
> de facto standard [I assume linux developers are reasonable so changing
> the page size to 8KB is not going to be a nightmare...]

4k may be the predominant size but by no means it's the defacto standard.

Some older ARM chips use 16k or 32k; Cris uses 8k; some 68k Suns using
the non-Motorola MMU use 8k also; sun4 and sparc64 both use 8k; IA-64 is
configurable to 4k (bad idea), 16k (prefered) and 64k.

On MIPS going for 4k was my choice in '95 ago because that's the pagesize
of the R3000 - and the i386 which eleminated a whole class of bugs in
porting.

It's now ten years later; everything is growing according to Moore's law
and some embedded systems that are considered small by today's standards
exceed what was a powerful workstation back then or even a full blown
supermini in '85 when the R2000 was created so increasig the page size
is overdue for most systems, MIPS and other.

> Since the mips cache is virtually indexed but physically tagged, I see
> two problems when the size of a cache way exceeds the size of a page:

Not all of them; it's just the most common cache policy.  There are also
PIPT caches and even VIVT I-caches.  I'll personally poke needles into
a doll of whoever should design VIVT D-caches ;-)

> - virtual aliasing. Can only happen on R/W pages (data cache) and only
> when two different virtual addresses map the same physical page. An
> example of this is: two processes sharing a memory area; should I
> consider this is taken into account by linux already?
> 
> - I was told the software exception handlers for tlb are much less
> efficient when cacheway > pagesize, forcing to flush too often. Is this
> true? What is, in practice, the ratio of instruction pages and data
> pages in a tlb?

The affected parts of memory managment are not part of the TLB exception
handlers in a strict sense but yes, on caches suffering from aliases in
situations where we can't use hit cacheops we need to flush nuber of ways
pages from the cache, so for a 4-way 32k cache that means half the cache.

Going to 16k pagesize would eleminate most such flushes entirely and as
a nice side effect also guarantee the correctness of a fairly complex
to get right piece of code by simple eleminating the need for it.

> If I consider a platform like Toshiba TX39 which has d-cache four ways
> with total 32KBytes, it must already have the problems above. I'd like
> to get some more clues though...

My paper says different numbers ...

  Ralf

RE: ...cache dimensioning ;-)

[Adrian Hulse]

>If I consider a platform like Toshiba TX39 which has d-cache four ways
>with total 32KBytes, it must already have the problems above. I'd like
>to get some more clues though...

You probably meant to say Tx49 no ? The Tx39 has 16/8 k Instruction
Cache, 8/4 k Data cache.



**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. 

RE: ...cache dimensioning ;-)

[Adrian Hulse]

>If I consider a platform like Toshiba TX39 which has d-cache four ways
>with total 32KBytes, it must already have the problems above. I'd like
>to get some more clues though...

You probably meant to say Tx49 no ? The Tx39 has 16/8 k Instruction
Cache, 8/4 k Data cache.



**********************************************************************
This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. 

RE: ...cache dimensioning ;-)

[Emmanuel Michon]

On Fri, 2004-09-10 at 20:41, Adrian Hulse wrote:
> >If I consider a platform like Toshiba TX39 which has d-cache four ways
> >with total 32KBytes, it must already have the problems above. I'd like
> >to get some more clues though...
> 
> You probably meant to say Tx49 no ? The Tx39 has 16/8 k Instruction
> Cache, 8/4 k Data cache.

Sorry, yes, TX4938 (so far I could not boot linux from linux-mips cvs
tag 2_4_26 on this (I chose TX49[23]7 platform))

> 
> 
> 
> **********************************************************************
> This e-mail is the property of Lantronix. It is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential, or otherwise protected from disclosure. Distribution or copying of this e-mail, or the information contained herein, to anyone other than the intended recipient is prohibited. 
>