[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[f-cpu] tlb




> The otherdraw back of many different size is that the OS must find "big
> and aligned hole" in memory to give such pages to a program and that
> could be hard !(having many sized from 4kb could help to reduice such
> problem)

A buddy system allocator with power-of-two page sizes should be ok.

>>> ??? a simple algorythme could be fine but with typical use there is a big risk to be very fragmented and never find such hole. Or you need to remap a lot of page.

> It could be very important to have 2 tlb (one for data and one for
> code), it's quite unusual to mix the 2 kind of pages. So you could save
> one port to the tlb or double the bandwith of the all system. (it could
> be very important if we keep the L1 cache in the physical address space
> and check at allmost every memory access the tlb)

There's no need to check the TLB on every instruction fetch. The
virtual->physical mapping remains valid until we leave the page or the
TLB entry is changed or invalidated - and that will be rather rare if
the compiler generates good code.

>>>> i dont understand you. If the L1 caches is on the physical address space, you always have to check the data (minus the trick with the LSU which is a kind of L0 caches in virtual space)
nicO

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/