[comp.unix.i386] 386 Motherboards

davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (05/03/90)

In article <292@zds-ux.UUCP> gerry@zds-ux.UUCP (Gerry Gleason) writes:
| In article <883@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) write| >In article <332@hub.cs.jmu.edu> arch@hub.cs.jmu.edu (Arch Harris) writes:

| >  I believe there are, but my personal experience is that over 64k you
| >hit diminishing returns (actually 32k does a lot).
| 
| This fits with some tables Intel published on various cache organizations
| and sizes, and with my experience.  However, the data also makes it clear
| that organization makes a big difference too, that is 32k 4way set-assoc.
| could end up about the same hit rates as 128k direct mapped (I don't have
| the data in front of me, but I remember that set-assoc. buys you quite
| a bit).  Also, keep in mind that those last few pecent of hit rate can
| make a big difference if the main memory is very slow.

  A good point. I stand clarified if not actually corrected. Something
which has 95% hit instead of 90% goes to main memory only half as much.
Now the question is, what does that cost in terms of wait states?
That's very machine dependent, but let's assume two. Then,

0.90 * 2w/s + 0.10 * 4w/s = 2.2w/s (effective)
0.95 * 2w/s + 0.05 * 4w/s = 2.1w/s

A gain of 5%. If you assume 6w/s (slow but not unheard of)

0.90 * 2w/s + 0.10 * 6w/s = 2.50
0.95 * 2w/s + 0.05 * 6w/s = 2.20

A gain of 12%. Finally, if you assume 6w/s and 16 bit memory (yecch)

0.90 * 2w/s + 0.10 * 12w/s = 3.00
0.95 * 2w/s + 0.05 * 12w/s = 2.50

A gain of 17%. If you make the main memory slow enough you can justify a
lot of cahce, and be making a good decision. I think the last case is
pretty unlikely, but I'm told that you can get 12 clock access with 32
bit memory on access to non-interleaved memory.

  The question then gets cloudier when you consider that doubling the
cache size doesn't double the hit rate (or more accurately halve the
miss rate) for most loads. So while it's probably true to say that more
cache or faster memory will always make your system faster, it's not
true that any kind of memory will always be the most cost effective
improvement to a system. Maybe adding an FPU or a better disk controller
will do more.

  People are still getting master's theses from this, so we're not going
to solve it in a screen or two.
-- 
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
    sysop *IX BBS and Public Access UNIX
    moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me

mat@zeus.opt-sci.arizona.edu (Mat Watson) (05/03/90)

I've been following this thread about cache hits with some interest,
and I'd like to ask you guys a couple questions:

Since *nix swaps entire jobs ( which I assume are larger than the
cache ), doesn't that screw up the hit rate?

And:

What makes the Logix board without cache different from other boards
without cache?

--Mat             mat@zeus.opt-sci.arizona.edu [128.196.128.219]
...{allegra,cmcl2,hao!noao}!arizona!zeus.opt-sci.arizona.edu!mat
Optical Sciences Center, Univ. of Arizona, Tucson, AZ 85721, USA

mat@zeus.opt-sci.arizona.edu (Mat Watson) (05/03/90)

I've gotten some responses to my posting, and
I STAND CORRECTED!  Thanks for setting me straight.

I wrote:
>   Since *nix swaps entire jobs ( which I assume are larger than the
>   cache ), doesn't that screw up the hit rate?

Not True.  I'm told that Unix seldom swaps out entire jobs,
so the cache actually ends up working pretty well on a single
user system.

--Mat

paul@dialogic.com (The Imaginative Moron aka Joey Pheromone) (05/03/90)

In article <MAT.90May2214726@zeus.megaron.arizona.edu> mat@zeus.opt-sci.arizona.edu (Mat Watson) writes:
>
>Since *nix swaps entire jobs ( which I assume are larger than the
>cache ), doesn't that screw up the hit rate?

False premise. Unix V/386 rel 3 is primarily demand paged. It *does* swap
complete jobs, but only under peculiar circumstances and great duress.
The prime memory managment scheme is demand paging.



--
Paul Bennett	      |  			| "I give in, to sin, because
Dialogic Corp.	      |   paul@dialogic.UUCP	|  You have to make this life
300 Littleton Road    | ..!uunet!dialogic!paul	|  livable"
Parsippany, NJ 07054  |	 			|  Martin Gore

dwc@cbnewsh.ATT.COM (Malaclypse the Elder) (05/04/90)

In article <MAT.90May3084057@zeus.megargon.arizona.edu>, mat@zeus.opt-sci.arizona.edu (Mat Watson) writes:
> I've gotten some responses to my posting, and
> I STAND CORRECTED!  Thanks for setting me straight.
> 
> I wrote:
> >   Since *nix swaps entire jobs ( which I assume are larger than the
> >   cache ), doesn't that screw up the hit rate?
> 
> Not True.  I'm told that Unix seldom swaps out entire jobs,
> so the cache actually ends up working pretty well on a single
> user system.
> 
actually, if you consider process switches instead of swaps,
then you have a point.  if the cache is a virtual one, then
process switches will result in cache flushes (unless there
is a process id tag in the cache).  if the cache is a physical
one, then you don't have to worry unless there is either a
process swap, a page replacement, or a process exit.  but in
this case, you are sharing your 64K cache (or whatever size)
with other processes.

danny chen
att!hocus!dwc

pb@idca.tds.PHILIPS.nl (Peter Brouwer) (05/04/90)

 In article <MAT.90May3084057@zeus.megargon.arizona.edu> mat@zeus.opt-sci.arizona.edu (Mat Watson) writes:
>I've gotten some responses to my posting, and
>I STAND CORRECTED!  Thanks for setting me straight.
>I wrote:
>>   Since *nix swaps entire jobs ( which I assume are larger than the
>>   cache ), doesn't that screw up the hit rate?
>Not True.  I'm told that Unix seldom swaps out entire jobs,
>so the cache actually ends up working pretty well on a single
>user system.
>

In a paging system pages are loaded on demand and if memory gets thight
pages are swapped.
If a page is swapped out or in it is copied through a few buffers in memory
in the kernel code. Like from the memory from the disk controller into a
kernel buffer and from that to the location in memory where it will be used.
Does this not trash the cache?



-- 
Peter Brouwer,                # Philips Information Systems,
NET  : pb@idca.tds.philips.nl # Department SSP-P9000 Building V2,
UUCP : ....!mcsun!philapd!pb  # P.O.Box 245, 7300AE Apeldoorn, The Netherlands.
PHONE:ext [+31] [0]55 432523, # 

rcd@ico.isc.com (Dick Dunn) (05/05/90)

dwc@cbnewsh.ATT.COM (Malaclypse the Elder) writes:

> ...if the cache is a virtual one, then
> process switches will result in cache flushes (unless there
> is a process id tag in the cache).  if the cache is a physical
> one, then you don't have to worry unless there is either a
> process swap, a page replacement, or a process exit.  but in
> this case, you are sharing your 64K cache (or whatever size)
> with other processes.

Caches on 386 systems are, of necessity, physical-address caches:  The
virtual-to-physical mapping happens on-chip; the processor presents a
physical address on the pins.

The case of process exit doesn't matter directly, since the pages are just
freed.  It will matter when a frame (or whatever you want to call it, the
physical-memory container for a page) is reassigned.  Process-swap and
page-replacement also come down to the same thing:  You have to do some-
thing when you reassign physical memory.  This just means that the cache
has to know (or be told) when memory locations are modified.  It knows
about CPU accesses, of course; it's DMA that it has to worry about.

As for sharing the cache, yes, that's an issue.  The interesting questions
have to do with how many active processes you've got, how often you allow
switching among them, and how much active memory you've got in each
process.  Although we lament how programs seem to be growing without bound,
the most active areas in programs still tend to stay small.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Lately it occurs to me what a long, strange trip it's been.

rcd@ico.isc.com (Dick Dunn) (05/05/90)

pb@idca.tds.PHILIPS.nl (Peter Brouwer) writes:

> In a paging system pages are loaded on demand and if memory gets thight
> pages are swapped.

This is a confusion of terms.  "Paging" refers to movement of individual
pages from a process.  To avoid confusion, the process of cleaning a page--
that is, writing out the contents of a modified page frame so that it can
be reused to "page in" something else--is normally called a "pageout".

That way, "swapping" can be used to refer to wholesale movement of
processes in/out of memory:  When memory commitment gets too high, you can
"swap out" a process--meaning to remove ALL of its pages from physical
memory.

> If a page is swapped out or in it is copied through a few buffers in memory
> in the kernel code. Like from the memory from the disk controller into a
> kernel buffer and from that to the location in memory where it will be used.

No, pages don't go through the buffer cache.  The page goes, in effect,
between the disk controller (which, although it may be "memory", is not
system memory and is not subject to the main memory-system caching) and
the physical memory where it belongs.  Thus this only affects caching to
the extent that bringing in a page replaces any cached locations for that
page--which is just what you want.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...Lately it occurs to me what a long, strange trip it's been.