> > Assuming you still want to keep "L1 "way size" = page size, that gives you
> > 8 cachelines per "way". I think once ARM made a 32-way L1 cache that they
> > claimed it was faster as 32-way, but that was certainly the exception.
> >
> > Do you want "60-way" caches?
>
> No.
>
> > Add some sort of inital TLB lookup to the L1 latency
> > (which of course would require more entries, because smaller pages)?
>
> I don't know what your question is.

I think that refers to VIPT caches, where way size = page size is natural?

But K10 got 3 cycle latency with a 64K 2-way L1D, so clearly way size = page size isn't the only way to go.

> > It might have worked for the 386, but I think the more advanced RISCs and P6 might have had
> > a lot of difficulty with L1 cache design and fast TLB lookup. And things would only get worse.
> > And I'm really guessing that HDD transfer rates were the real reason for the 4k size.
> >
> > Even modern disk drives use 4k pages, although I'm sure that has more to do with newer ECC
> > algorithms (and the need for their efficiency) than any underlying preference for 4k pages.