Obvious coherence filter idea?
|
Prev: Warning for laptop users: Starcraft 2 can overheat your computer. (any game can really ;) :))
Next: +++ NFL Jerseys On Sale at www.ajerseys.com
From: Paul A. Clayton on 3 Aug 2010 12:26 Might it not make sense to use different granularity bloom filters for coherence filtering? (I have read suggestions of using bloom filters in coherence and having page-granularity coherence, so merging the two seems obvious--especially given the multiple-hash nature of bloom filters.) Unfortunately, I cannot think of a good way to maintain a page-grained filter given the cache-block granularity of most coherence. One could count cache blocks, perhaps compressing the counters by having a set selector information (perhaps with four states: no-entries, use hash#1 of address, use hash#2 of address, merged entry--interestingly, identifying the hash used to select the set could slightly reduce false positives: if the entry is zero, then the entry must have applied to a different value [with even more complexity, one could steal entries: if adjacent filter entries are in the no-entry state, a two-bit version of the hash could be used {reading two extra bits might not be that much overhead relative to the row decode} requiring the counters to be merged when the entry is reclaimed--an alternative might be to store a partial tag in the 'empty' counter(s)]). (Using different hashing functions for different coherence filters might be useful for further constraining coherence traffic. [For a two-memory node system, the filter for each node might be for local- only memory since a non-local miss needs to retrieve the data from the other memory anyway and ownership updates are less bandwidth intensive and less latency sensitive.]) Paul A. Clayton just a technophile |