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

Re: [f-cpu] tlb

On Tue, Jul 16, 2002 at 12:04:16AM +0200, nico wrote:
> 
> > 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.

You'll *always* have that problem if you have multiple page sizes.

BTW: sometimes, a little garbage collection isn't so bad :)

> > 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)

I'm not talking about data, I'm talking about code. Instruction fetches
happen at consecutive addresses (unless there is a jump or trap),
therefore you know when you will hit the end of the current page
(every 1024 instructions if your code is linear and pages are 4K).

-- 
 Michael "Tired" Riepe <Michael.Riepe@stud.uni-hannover.de>
 "All I wanna do is have a little fun before I die"
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/