Re: [f-cpu] TLB design

[Cedric BAIL <cedric.bail@free.fr>]

> I've been thinking about the TLB before; IMHO, we need at least the
> following (assuming <n> bits for the page offset):
> 
> 	- virtual address (64-<n> bits)
> 	- physical address (64-<n> bits)
> 	- address space identifier (ASI; 8 bits was suggested)
> 	- supervisor access rights (RWX, 3 bits)
> 	- user access rights (RWX, 3 bits)
> 	- valid bit (indicating that the entry is valid)
> 	- present bit (indicating that the page is in memory)
What did you mean whith this bit ?

> 	- dirty bit (indicating that the page has been written to)
Same question.

> 	- used bit (indicating that the page has been accessed)
Why not a counter ? I currently don't see how the OS can make it's decision
about how to remove a TLB entry if TLB is full.
 
> The latter can be used to implement an LRU algorithm.
 
> That is, we need 128+2*<n>-18 bits. If an entry shall fit into 128 bits,
> <n> must be at least 9 (i.e. a page must have at least 512 bytes).
> With 4K pages, we will have 6 bits left. Some (or all) of them may be
> used to indicate the page size.
That's a really nice idea in fact. But what did this bit mean, are they
number of Ko for a page, or predefined size page ?

> A TLB lookup is performed by XORing the address and ASI fields with the
> actual values; if the result is 0, the entry matches. If we are going
> to use multiple page sizes, the result must be ANDed with a mask that
> depends on the page size.
 
> The question is how we choose the page sizes. With 4K/32K/256K/2M
> pages and 8 entries per size we can map only ~18M of memory at the same
> time, and we will have a hard time if we want to map arbitrary segments
> (with sizes that are not a power of two). Additionally, the CPU will spend a
> lot of time inside the TLB miss handler. Note that there are applications
> that easily take megabytes of code space and hundreds or even thousands
> of megabytes of data -- that's the kind of program a 64-bit CPU is most
> useful for, because it has a large address space.

> It's probably better to provide all page sizes that are powers of two,
> from 4K up to at least 4G. It may also be a good idea to implement a
> `best match' strategy: if multiple TLB entries match a virtual
> address, the most specific one (that is, the one with the smallest page size)
> is chosen. That way you can put small `windows' inside a bigger page.
> The total number of TLB entries should not be smaller than 256.

That's a great idea, and if can do it in the F-CPU it will be really nice.
I really like your idea and I think it will solve a lot of TLB problem.

Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/