|
From: Julian S. <js...@ac...> - 2002-11-21 23:26:07
|
> > > A questions: What's the deal on the LRU mechanism when > > > chaining is going, now? > > > > I did notice the problem and made a small attempt to address it: > > patch_me updates the epoch field in the same way as the dispatch loop. > > It doesn't actually help much, but it looks like I paid attention to it. > > > > I was thinking of a scheme like an OS VM scheme: have a loop go through > > the TTEs at some low rate and unchaining blocks; if on the 2nd pass the > > block is still unchained and still hasn't updated the LRU entry, then > > consider it old. Ha, that sounds like it might work well enough. I sometimes wondered how OSs implement the pseudo-LRU stuff for VMs. Is there a standard description of this, that you know of? > It might be worth re-mentioning the approach used by Dynamo, Walkabout, > Strata and seemingly all the other dynamic translators for handling this > situation -- they just flush the code cache. > > But they have smaller translations and smaller code caches, and spend less > time on translations. And I think Julian's LRU mechanism is extremely > fast. So maybe just ignore this. Yes, that is the simplest thing, but I fear it would be very expensive. A less radical similar scheme is to randomly discard some fraction of the translations. Then you get into schemes where you randomly move some fraction of the translations into a "victimisation cache" (in hardware speak). If they turn out to be needed again soon, they can be moved back from the cache back into the main set of active translations. If the V-cache gets full _it_ then is flushed. This scheme has the effect of somewhat mitigating the situation where a translation is randomly selected for demotion and then used again soon afterwards. But it's all a bit complex. J |