It gets even more complicated with multiple CPU's. See Cache Basics for the simpler stuff and Unix Systems for Modern Architecture if you really want to dig in.
From: John-Paul Stewart <jpstewart@sympatico.ca> Subject: Re: memory issues References: <pan.2002.04.22.16.53.27.930714.5279@NOSPAMeas.gatech.edu>
<Gv4F3q.My7@fcshome.stoneham.ma.us>
<slrnachi4c.2lc.dhbrown@hobbes.dhbrown.net>
<aab20i$96m7e$1@ID-87867.news.dfncis.de>
<slrnacjfji.3ub.dhbrown@hobbes.dhbrown.net> Date: Sat, 27 Apr 2002 11:46:44 -0400 Dave Brown wrote: > > In article <aab20i$96m7e$1@ID-87867.news.dfncis.de>, florian schmidt wrote: > > On Fri, 26 Apr 2002 05:25:10 +0200, Dave Brown wrote: > > > >> Your understanding of motherboard cache is totally different from mine. > >> (And I'm afraid one of us is wrong.) The only caching that is done by > >> the motherboard is the L1 and L2 caching which are "instruction caches" > >> usually in the neighborhood of 512KB. The idea is that the execution of > >> a program can often be speeded by caching routines that are frequently > >> reused, without having to always fetch instructions from slower main > >> memory. (So no motherboard caches anything like 64 MB!) > >> > > > > hmm, well L1 cache is usually on the cpu-die.. but what he was referring > > to where these intel chipsets from a while back. they could handle more > > than 64megs of ram, but like he said, the L2 cache would only cache > > memory words up to a magic 64-meg limit.. so the memory anove 64megs > > never got cached and consequently accesses to memory above 64 meg were > > pretty slow (since there are no cachehits).. > > > > don't hit me if i'm wrong.. > > Hmm... Typical motherboards have 512KB of SRAM for L2 cache, so it's hard > to see how 64MB could be cached in 512KB. Perhaps it's an architecture > that causes accesses to the lower 64MB of memory to go through the cache, > but outside of that address space the L2 cache is bypassed. Seems like an > unfortunate architectural decision, but then so was the old 640K memory > space for Intel PCs. When you access a certain point in RAM, it is presumed that the next access will be to an adjacent location. So those adjacent locations get transferred to cache on the assumption that they'll soon be needed. (Cache being around ten times faster than main memory.) This is how 64MB of RAM can be cached in 256 or 512KB.
Now, the cache needs to know which addresses from main memory are in it. Each "line" of cache is tagged with its address from main memory. But there's a certain number of bits in the tag. If there are 32 bits in the tag, you can cache anywhere in the first four gigs of RAM. Evidently Intel's Triton chipset (for Pentiums) had only 26 bits in the tag, for a cacheable area of 64MB. IIRC, early P-IIs could cache the first 512MB, and current P-IIIs can cache 4GB. (Keep in mind at the time the Pentium was introduced 64MB was _huge_. 8MB of RAM was common then. Similarly, 512MB in the early P-II days was a lot. It was a design trade-off made with the assumption that users were unlikely to hit the limit.) As a side note, the cache is no longer on the motherboard. The Pentium Pro incorporated it into a "Multi-Chip Module". Essentially one physical (ceramic) package with both the CPU core and cache on seperate silicon chips inside. The cartridge-style P-IIs and early P-IIIs had their CPU chips and cache RAM on a small circuit board under the plastic shroud. Coppermine and newer P-IIIs (and P-IVs, AFAIK) have the cache on the same (silicon) chip as the CPU core. The above is a _huge_ oversimplification, but it should make it clear how small amounts of cache can handle huge amounts of RAM, and why some caches handle more RAM than others. If you have more questions, ask away. (And if you're lucky, somebody who knows more than I do will answer!)
HTH, J-P Stewart
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.
Click here to add your comments
Don't miss responses! Subscribe to Comments by RSS or by Email
Click here to add your comments
If you want a picture to show with your comment, go get a Gravatar