Caching of information according to popularity
A system includes logic to cache at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of other blocks in the cache, where the popularity of the block is determined by reads of the block from persistent storage and reads of the block from the cache.
1. A method comprising:
caching at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of blocks in the cache, where the popularity of the block is determined by real reads of the block from persistent storage and reads of the block from the cache;
only when the block is a parity block, the popularity of the block is determined by reads of the block from persistent storage and reads of the block from the cache, whether real or contingent.
2. The method of claim 1 , wherein the caching at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of blocks in the cache further comprises:
caching the block if it is one or more of as popular, more popular, or as or more popular than at least one other block in the cache.
3. The method of claim 2 , wherein the caching the block if it is as popular, more popular, or as or more popular than at least one other block in the cache, further comprises:
caching the block if it is as popular as the at least one other block in the cache and more recently read than the at least one other block.
4. The method of claim 1 , wherein the caching at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of blocks in the cache further comprises:
caching the block on a node of a multi-node stream server, the node where the block is cached comprising mass storage where the block is stored.
5. The method of claim 1 , wherein the caching at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of blocks in the cache further comprises:
the popularity of the block determined at least in part by how many reads of the block have occurred from mass storage or cache over one or more intervals of time.
6. The method of claim 1 , further comprising:
not caching the block if the popularity of the block does not compare favorably with the popularity of the other blocks in the cache, even if the block is read more recently than at least some of the other blocks in the cache.
7. The method of claim 1 , further comprising:
replacing the block if the popularity of the block does not compare favorably with a replacement block, even if the block is read more frequently from cache than the replacement block is read from persistent storage.
8. The method of claim 1 , further comprising:
each node of a multi-node media server maintaining popularity of blocks persistently stored by the node.
9. The method of claim 1 , further comprising:
applying at least one decay function to block popularities.
10. The method of claim 9 , wherein applying at least one decay function to block popularities further comprises:
reducing at least some of the block popularities after an amount of time has elapsed.
11. The method of claim 10 , wherein reducing at least some of the block popularities after an amount of time has elapsed further comprises:
dividing at least some of the block popularities by some amount after the amount of time has elapsed.
12. The method of claim 9 , wherein applying at least one decay function to block popularities further comprises:
reducing the block popularities in a manner that preserves a popularity order.
13. The method of claim 9 , wherein applying at least one decay function to block popularities further comprises:
applying the decay function as a result of at least one block reaching a popularity limit.
14. The method of claim 1 , further comprising:
initializing at least some block popularities as a result of a startup and-or reset situation.
15. The method of claim 14 , wherein initializing at least some block popularities as a result of a startup and-or reset situation further comprises:
initializing block popularities at least in part according to popularity histories of the blocks.
16. The method of claim 14 , wherein initializing at least some block popularities as a result of a startup and-or reset situation further comprises:
initializing block popularities at least in part according to the media streaming and-or viewing histories of programs comprising the blocks.
17. The method of claim 14 , wherein initializing at least some block popularities as a
result of a startup and-or reset situation further comprises:
initializing block popularities at least in part according to popularities of blocks of adjacent storage locations.
18. The method of claim 17 , wherein initializing block popularities at least in part according to popularities of blocks of adjacent storage locations further comprises:
initializing the block popularities at least in part according to popularity of blocks of adjacent RAID storage locations of different nodes of a media server hypercube.
19. A system comprising:
machine memory or non-transitory machine-readable media embodying logic to cache at least one block in at least one cache if the block has a popularity that compares favorably to the popularity of other blocks in the cache, where the popularity of the block is determined by real reads of the block from persistent storage and reads of the block from the cache; only when the block is a parity block, the popularity of the block is determined by reads of the block from persistent storage and reads of the block from the cache, whether real or contingent.
20. The system of claim 19 , wherein the logic to cache at least one block if the block has a popularity that compares favorably to the popularity of other blocks in the cache further comprises:
machine memory or non-transitory machine-readable media embodying logic to cache the block if it is one or more of as popular, more popular, or as or more popular than at least one other block in the cache.