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.

  • 1
    What 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 – mikeserv Mar 31 '14 at 8:21
  • I wanna use this concept in my paper so i need more details about them . – Amir Hadifar Mar 31 '14 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. – Bratchley Apr 1 '14 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. – mikeserv Apr 1 '14 at 21:47
up vote 12 down vote accepted

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.

  • 7
    As 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 :) – Riking Mar 31 '14 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). – Bratchley Apr 1 '14 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. – Bratchley Apr 1 '14 at 20:36
  • The disk is a cache of RAM? – Bratchley Apr 1 '14 at 20:42
  • 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. – Bratchley Apr 1 '14 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

  • "recently or frequently"? Recently, yes. but frequently? – Faheem Mitha Mar 31 '14 at 9:46
  • 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. – mikeserv Mar 31 '14 at 10:03
  • @cpugeniusmv Thanks for the link. That could reasonably be included in your answer. – Faheem Mitha Mar 31 '14 at 10:55

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.