How can too much cache memory be a bad thing?

[dalearyous]

i have read this but it doesn't make sense.

 

[Yanagi]

I have an analogy, it might put things in a too of simplistic term but someone can gladly correct me on this one then.

If you think of the cache as a library, all the books are a byte, aisles are column addresses and so on.

Now, if you were to find a specific book for a specific task, in which of the two libraries would you find out the fastest if the book was actually there or not, the big one or the small one (assuming you will search manually)?

Thats about the only thing I can come up with really and if I oversimplified it so much that it has become incorrect someone will let us know

 

[dalearyous]

i found the answer that i can understand FINALLY

But, to make use of cache, the CPU has to add a step where it has to 'look up' then address stored in the cache first to see if an address' data is _already_ in the cache before fetching it from RAM. This 'lookup' takes more time than direct access to RAM and can have an adverse affect on speed if cache is too large for the processor or it is mismanaged. In the old days of desktop computing, the mid '80s and early '90s, cache was purchased and installed separately in little slots next to the CPU on the mainboard, and it was possible to install too much cache.

 

[faxon]

rofl that article you linked is HORRIBLE. i couldnt make heads or tails of it half the time because it literally DID NOT make any sense. they completely abused the term cache to refer to the system's RAM and swap file (page file, virtual memory, whatever you want to call it its all the same), which is going to severely confuse less than informed readers when they are trying to upgrade their Dell because it isnt running as fast as they want it. they are going to think they need more cache, and are going to call dell and tell them as such, only to buy a significantly more expensive CPU which probably isnt going to fix any of their problems nearly as much as adding another 2GB of RAM would, which is what the article is actually about, your system needing more physical RAM than it actually has. i left a pretty long comment there about this so if anyone else wants to chip in go ahead

 

[Idontcare]

Originally posted by: dalearyous
i found the answer that i can understand FINALLY

But, to make use of cache, the CPU has to add a step where it has to 'look up' then address stored in the cache first to see if an address' data is _already_ in the cache before fetching it from RAM. This 'lookup' takes more time than direct access to RAM and can have an adverse affect on speed if cache is too large for the processor or it is mismanaged. In the old days of desktop computing, the mid '80s and early '90s, cache was purchased and installed separately in little slots next to the CPU on the mainboard, and it was possible to install too much cache.

I guarantee you looking up the address of the data in cache is ridiculously faster than looking up the address of that data in ram.

Think about it. Accessing ram is not the same as looking up the address in ram. Just as accessing cache is not the same as looking up the address in cache.

You (or your source) are comparing apples to oranges.

The round-trip time to access cache, find data address, send data to CPU's L1 cache is always faster than doing the same thing with DRAM.

Just as doing a round-trip thru the DRAM loop is always faster than doing the same round-trip to get data off your hard-drive.

Think about it.

 

[faxon]

IDC i think you are missing the point about how when the CPU cache wasnt on the CPU die, it was actually significantly slower than the actual operational speed of the processor, as it ran at some multiple of the motherboard speed. of course, this was only true of the L2 cache, as the L1 cache has always been on the CPU die as far as i know. if the cache was large enough, cycling through the addressing on the cache could in theory be slower than cycling through a certain quantity of ram where the data you need might be located. this is obviously NOT true though if the cache is on the CPU die itself since it is operating at the same frequency of the CPU (in most cases) and doesnt have the latency of going out to DRAM. also, if there was enough cache available to store all your data, making it unnecessary to use RAM instead of just cache in the first place, we would never run into this problem, and this will typically only occur if you have way more cache than your CPU can utilize relative to the amount of RAM the system has, since there will always be files that wont fit in CPU cache at the current cache/memory ratios. if anyone would like to learn more about exactly how cache and memory performance works, it is covered in detail in chapter 3 and 6 of Scott Mueller's Upgrading and Repairing PCs, 18th edition, ISBN-13: 978-0-7897-3697-0 or ISBN-10: 0-7897-3697-7 (which im currently holding). also a great resource to have since it covers some of the most highly technical aspects of the business that most tech classes wont cover, but which can be extremely beneficial in troubleshooting issues you may uncover when working with PCs

 

[Phynaz]

Ummm...The linked article is talking about operating system disk caching, not cpu cache.

 

[VirtualLarry]

"The system cache's working set limit can and typically does exceed how much memory is installed in the system," explained the member of the Microsoft NTDebugging team."

That sounds like a severe bug. The whole point of RAM-based caching is it's faster than disk. But if it grows so much that some of it gets paged out to disk, then it's not an advantage any more. You would think Microsoft would be more careful than this.

 

[VirtualLarry]

I would move this thread to Operating Systems, where some of the heavyweights there can chime in on this article.

 

[Nothinman]

That article is retarded. You can't have too much filesystem cache. How the kernel deals with memory when pressure gets high is a completely separate issue.

And the article is full a lot of incorrect details.

Write I/O will be buffered and the working set of the system cache will expand. Ultimately, system threads will be dumped to the hard disk, and this is where the problem will occur, because of the differences in speed management between the disk's speed and that of the I/O write. The exception typically occurs when the cache manager, because of a faulty application or service, will be unable to handle throttling I/O. But at the same time, excessive cached read I/O will also present problems.

If you've got a lot of write I/O then you're going to have I/O contention because disks are so slow, there's no way around that. If you've got 4G of memory and some process is trying to write out 16G of data you want some of it to be buffered in memory otherwise the disk will be too busy writing to service anything else and he machine will be just as non-responsive.

And threads don't get dumped to the disk. There may be some pages in a certain process/thread's working set that is pushed to disk because they're modified but the process itself, shared libraries, etc won't because they're already backed by the files they were read in from originally.

If an application or driver opens many files and actively reads from them continuously through the cache manager, then the memory manger will move more physical pages to the cache manager. If this demand continues to grow, the cache manager can grow to consume physical memory and other process (with less memory demand) will get paged out to disk. The system cache's working set limit can and typically does exceed how much memory is installed in the system," explained the member of the Microsoft NTDebugging team.

Again if you've got some errant process reading gigs and gigs of data of course it's going to cause I/O contention. Even if the OS wasn't trying to cache the reads that process would still monopolize the drive by just constantly reading data. And again, whole processes don't get paged out.

But, to make use of cache, the CPU has to add a step where it has to 'look up' then address stored in the cache first to see if an address' data is _already_ in the cache before fetching it from RAM. This 'lookup' takes more time than direct access to RAM and can have an adverse affect on speed if cache is too large for the processor or it is mismanaged.

You've got the process correct but a lookup in the TLB is definitely not slower than reading from memory. If that were the case OSes wouldn't use the TLB anymore. In fact one of the things I've gleaned from reading lkml is that TLB flushes are to be avoided like the plague for performance reasons on x86 (not sure about AMD64) because lookups going directly to the pagetables in memory take so much longer.

That sounds like a severe bug. The whole point of RAM-based caching is it's faster than disk. But if it grows so much that some of it gets paged out to disk, then it's not an advantage any more. You would think Microsoft would be more careful than this.

Actually since the pagefile is an indexed entity with it's extents close together or contiguous it would probably end up being faster most of the time to get data from there than to look it up in the MFT then go find it in the filesystem.

 

[Xcobra]

nvm