|
From: Nuno L. <nun...@sa...> - 2008-04-18 16:02:36
|
>> When the oldest sector is purged, it searches all >> the others sector's blocks for patched jumps and unpatches thems. > > I'm confused. I was just trying to describe the valgrind 2.4 behaviour for a sanity check. I think I read it correctly, but I was just trying to confirm if I got it correctly. >> cost may be prohibitive (where adding a little table to each superblock >> with back-pointers to referencing blocks > > I think that is the "standard" solution. > >> that the case? I dunno about the perftests, but I assume they are so >> small >> they don't even fill up the whole cache, right? > > The cache is huge, really, very large. It rarely fills up. > To fill it up completely requires (eg) starting OpenOffice, loading a .ppt > presentation and a .doc document, so as to force V to translate all the > Powerpoint import code and all the Word import code. > > For meaningful testing/evaluation, you will need to make it much smaller, > by changing N_TTES_PER_SECTOR in m_transtab.c to some small prime number > (use auxprogs/primes.c to produce prime numbers). So that means that the more or less "naive" solution to scan all blocks is not that bad, right? Well, at least it saves some memory and all the bookeeping. >> Out of curiosity: why did you change from FIFO to LRU in valgrind 3? I'm >> only asking this because that thesis suggests that FIFO may be better. > > V 3 uses FIFO; we haven't used LRU in a very long time. LRU has the > disadvantage that you need to make some kind of mark/stamp every time > a translation is used, which reduces performance. FIFO avoids that. My bad. I probably read that LRU thing in an old paper. Thanks, Nuno |