Re: Some initial thoughts about 2.4

[Sander Vesik <sander_traveling yahoo co uk>]

 --- Daniel Egger <degger fhm edu> wrote: > Am Mit, 2003-01-01 um 18.49 schrieb
Sander Vesik:
> 

> > many usefull re-orderings (like moving 
> > frequent caller-calle pairs to be next to each other) are beneficial in any
> > TLB you are likely to find in a shipping CPU.
> 
> What makes you think that? TLB management is part of the OS which is

Knowledge of what kind of TLBs, both from the point of view of organisation,
and user/kernel space visibility are shiping / have been shiping in widespread 
CPUs.

> free to choose how the TLB is organized and whether it uses the hardware
> for the management. And then the hardware is also differing; some don't
> have TLB hardware, some only support full flushes, many organize it as
> some form of tree while other use hashtables.
> I'm by no mean someone who knows much about TLBs so the above written is
> probably a bit off but I'm pretty confident that a generic
> implementation is somewhere between hard and impossible.
> 

Generic implementations of what? How the TLB miss handling happens is not 
something you really need to be concerned with, it is something that "just 
happens" as far as user space is concerned (yes, there are cases where this 
is not true - like figuring out worst case timings and similar). Neither does
the makeup of the page tables - hierarchical, inverse, etc - which is 
completely different thing to TLB). What reordering tries to do is make sure
that the iTLB misses as seldom as possible

TLB is a hardware cache (as far as lookups are concerned) misses in which 
may be be satisfied by either software or hardware. A tlb has a limited 
number of entries, each of which holds virtual->physical translation for
one page. A call that misses in the tlb can take signifcantly longer than
one that doesn't - for simple functions a 'call with tlb miss' can take
significantly longer than the same call without. 

If you manage to place a certain percentage of popular functions within K 
pages where K is smaller than the number of entries, the miss rate will 
go down. Similar reasons apply to placing functions that call each other 
within the same page - such a call can never incur a TLB miss.

> > You may want to use more than one application though.
> 
> Yeah, but that would complicate gathering the statistics quite a lot.
>

Possibly, dependening on what kind of data you gather,how, etc. The 
downside to not doing it is that the re-ordering might cover a small 
set of functions and/or benefit only a small set of applications. 
Just a question of efficency.
 
> -- 
> Servus,
>        Daniel
 

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com