APLawrence - Information and Resources for Unix and Linux Systems, Bloggers and the self-employed
RSS Feeds Get APLawrence.com by RSS











(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Home > News Posts > cpu memory cache l1 l2 ––>Re: memory issues
Printer Friendly Version




News Group Posts

cpu memory cache l1 l2


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
 

If this page was useful to you, please click to help others find it:  

Your +1's can help friends, contacts, and others on the web find the best stuff when they search.

Comments?



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



Auto FTP Manager

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.

Publishing your articles here

Jump to Comments



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.


My Troubleshooting E-Book will show you how to solve tough problems on Linux and Unix systems!


book graphic unix and linux troubleshooting guide


 I sell and support
 Kerio Mail server
g_face.jpg

This post tagged:

       - CPU
       - Hardware
       - Memory
       - SCO_OSR5




Unix/Linux Consultants

Skills Tests

Guest Post Here