By: anon2 (anon.delete@this.anon.com), May 5, 2021 4:04 pm
Room: Moderated Discussions
wumpus (wumpus.delete@this.lost.in.a.hole) on May 5, 2021 9:06 am wrote:
> anon2 (anon.delete@this.anon.com) on May 3, 2021 1:17 am wrote:
> > Ben LaHaise (bcrl.delete@this.kvack.org) on May 2, 2021 10:45 am wrote:
> > > Yuhong Bao (yuhongbao_386.delete@this.hotmail.com) on May 1, 2021 1:01 pm wrote:
> > > > The fun thing is that 4K pages probably used to be too large. On a 80386, just 8 tasks would consume
> > > > at least 64k and probably 128k just for the page tables alone. (80386 page tables were two levels)
> > >
> > > The National Semiconductor 32016 had 512 byte page sizes. The problem is that overhead of small
> > > page sizes becomes excessive as soon as you have more than a couple of megabytes of memory.
> > > With 16MB of RAM and 512 byte pages that works out to 65536 pages for which data structures
> > > to track all the individual pages are needed.
> >
> > That's what Linux does, but it is not necessarily the best size/speed tradeoff for very
> > small memory systems. Tracking per page data with 4k pages and 64 bytes per page is
> > still 25% the overhead of your "unviable" solution, which doesn't sound great when you
> > put it that way. That being said I don't think it's necessarily bad at all.
> >
> >
> 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.
>
> 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.
> anon2 (anon.delete@this.anon.com) on May 3, 2021 1:17 am wrote:
> > Ben LaHaise (bcrl.delete@this.kvack.org) on May 2, 2021 10:45 am wrote:
> > > Yuhong Bao (yuhongbao_386.delete@this.hotmail.com) on May 1, 2021 1:01 pm wrote:
> > > > The fun thing is that 4K pages probably used to be too large. On a 80386, just 8 tasks would consume
> > > > at least 64k and probably 128k just for the page tables alone. (80386 page tables were two levels)
> > >
> > > The National Semiconductor 32016 had 512 byte page sizes. The problem is that overhead of small
> > > page sizes becomes excessive as soon as you have more than a couple of megabytes of memory.
> > > With 16MB of RAM and 512 byte pages that works out to 65536 pages for which data structures
> > > to track all the individual pages are needed.
> >
> > That's what Linux does, but it is not necessarily the best size/speed tradeoff for very
> > small memory systems. Tracking per page data with 4k pages and 64 bytes per page is
> > still 25% the overhead of your "unviable" solution, which doesn't sound great when you
> > put it that way. That being said I don't think it's necessarily bad at all.
> >
> >
> 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.
>
> 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.
