Date: Sat, 8 Apr 1995 22:33:17 -0700 (PDT) From: "Rodney W. Grimes" <rgrimes@gndrsh.aac.dev.com> To: pete@pelican.com (Pete Carah) Cc: current@FreeBSD.org Subject: Re: Disk performance Message-ID: <199504090533.WAA17143@gndrsh.aac.dev.com> In-Reply-To: <m0rxp8a-000K0jC@pelican.com> from "Pete Carah" at Apr 8, 95 10:02:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > In article <199504081952.MAA15923@gndrsh.aac.dev.com> rgrimes writes: > (and various others, too): > > >> > > > Why would taking out the L2 cache slow down data transfer to and > >> > > > from the primary cache? > > >> > > because checking the L2 takes time, and they don't start the mem-cycle > >> > > until they know they missed. > > The SGI challenge starts both on the same clock, then throws away the > mem data if some cache hit first. I don't know if they abort the CAS > part of the memory cycle in that case, but I think not. That is part > of the distributed-cache-coherency scheme too. Doing this hurts you > badly in the absence of memory interleave, though, since you can't abort > a RAS-cycle; you are better off waiting like they do in that case. Ahhhh!! A good memory system! The cache hit signal usually comes valid before the CAS cycle has started, so they probably do abort the CAS cycle by dropping RAS at this point in time and never asserting CAS. You still have to wait the RAS precharge time after doing this though, since you have infact sucked the storage charge out of the capacitors during the RAS assertion :-(. > > >> > You would be right if he was talking about why turning off the L2 cache > >> > increases memory speed. But that is not what he said ``taking out L2 > >> > cache slowing down L1 cache''. Nothing, nota, zippo, should effect > >> > L1 cache speeds other than code changes, and internal clock frequency. > > Possibly worse hit rates; isn't the L2 controller on the main chip too? No, the L2 cache controller is completly external from the Pentium CPU. > Also L2 may be wider than main mem too and do background fetch of the other > half; I don't know about that motherboard. Bigger ($$$$$) systems do this. I haven't see a L2 cache wider than the CPU (well, other than in a certain prototype some place I saw.). Main memory was also widened in this design to 128 bits. > Then L1 fills will come from the L2 about half more often than from > main memory directly. > > -- Pete > -- Rod Grimes rgrimes@gndrsh.aac.dev.com Accurate Automation Company Custom computers for FreeBSD
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199504090533.WAA17143>