I read a paper and it used terms “cold cache” and “warm cache”. What does it mean by cold cache and warm cache concept? I visit this but I need something more.
4
-
1What would you regard as useful? How do you intend to use the information? I only ask because, you know: google.com/search?q=wikipedia+cold+cache– mikeservMar 31, 2014 at 8:21
-
I wanna use this concept in my paper so i need more details about them .– AmirMar 31, 2014 at 8:35
-
It's just using temperature as a metaphor for understanding how useful a particular cache is since "usefulness" exists on a continuum. Warmer caches have high hit rates whereas cold caches are filled with data you're probably not going to ask for again any time soon and so they're just taking up space.– BratchleyApr 1, 2014 at 20:41
-
@JoelDavis - If caches did not need to handle errors then the above would be true, and the only method of replacing cached data that would have ever needed developing would be LFU, but because data is prone to error for a variety of reasons, handling a cold cache is a little more complicated than just replacing least-used data.– mikeservApr 1, 2014 at 21:47
Add a comment
|
2 Answers
Well, in short: a warm cache is useful whereas a cold cache is not. In fact, a cold cache can be dangerous to use.
You see, the whole point of a cache is to keep oft-accessed data accessible. For instance a DNS cache will store locally the results of the name-resolutions that you've requested recently, and, when those same resolutions are requested again their results are already available and served immediately without querying a larger, likely off-site name database. In other words your computer doesn't have to ask your internet service provider's domain name server for the ip address to google.com because your computer already knows it - your DNS cache is warm.
But if you never request google's ip then it won't be in your cache. A cold cache is either too stale to be useful - as in the data it contains is likely too old to be accurate - or it is entirely empty, and empty's plenty cold.
But often empty is better than old - though this is highly dependent, of course, on the data that is being cached. Empty's easy to handle because it just needs filling - that's a no-brainer - but old caches require error-correction. This is the primary logistical problem of developing and maintaining cache systems - how can you know the data you've cached is up to date and what is done if it isn't?
I won't be answering either of those questions - they're both implementation dependent and probably far and away beyond my capability, anyway - but it should be understood that all caching systems come with some inherent risk of inaccuracy. It goes with the territory. The risk may not be great - often it is only a risk of a few extra nanoseconds in processing time. The cache system will check requested data against whatever failsafe has been implemented by the cache designer and, if it's found wanting, then the cache system will, for instance, query the ISP's DNS for google's ip and all is well.
The warmer the cache, though, the less there is risked. The warm cache's benefits of keeping dear data near outweigh the risks of the cold cache's drawbacks or... probably you shouldn't be caching.
-
7As the famous quote goes, "There are two hard problems in computer science: Naming things, Cache invalidation, and off-by-one errors." Knowing that your cached values are old is exactly what cache invalidation means :)– RikingMar 31, 2014 at 16:38
-
On your comment about cache inaccuracy, that's not necessarily true. If the system/application has exclusive access to the data source, then cache entries can be updated or evicted as appropriate. It's only if you're dealing with concurrently accessed sources (e.g DNS, NFS or CIFS) that you run into this problem (even if only one has write access, such as with DNS). Apr 1, 2014 at 20:25
-
"else why are you caching at all" Same reason you would have for caching anything else: protection against high latency. For example the filesystem cache is just so the OS doesn't have to go out to disk for common requests. The cache is still in a coherent state, though, since modifications to local filesystems would have to go through the kernel anyways. The ECC part isn't really relevant since that kind of corruption isn't due to caching being caching, it's due to a hardware error that would hit all systems equally no matter how they were designed. Apr 1, 2014 at 20:36
-
-
I think you have the relationship reversed. The recently accessed contents of disk are cached in RAM so memory is a cache for disk (or is at least used as part of the caching system). Disk access is the slow operation that storing stuff in memory is designed to get around. Apr 1, 2014 at 20:53
In general, a cold cache is one that is not well populated (yet). So if your cache is cold, information must be retrieved using the, presumably, slower method. This is typically the case shortly after an application starts up or the types of queries change significantly.
Conversely a warm cache is well populated with information that you have recently or frequently retrieved.
With respect to ext filesystems and directory structures, there is some information about how caching generally works in the Virtual File System (VFS) in Linux here: http://www.tldp.org/LDP/tlk/fs/filesystem.html
-
-
-
1@FaheemMitha It's true - LFU is definitely a very common acronym you'll encounter in this department. If your cache is reasonably certain to contain only recent information and it is full, then you must have some other means of determining which information is replaced as you read in new data. LFU is probably the way you'll go.– mikeservMar 31, 2014 at 10:03
-
@cpugeniusmv Thanks for the link. That could reasonably be included in your answer. Mar 31, 2014 at 10:55