Return to BSD News archive
Newsgroups: comp.os.386bsd.misc
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.oz.au!spool.mu.edu!agate!tfs.com!julian
From: julian@tfs.com (Julian Elischer)
Subject: Re: FreeBSD platform
Message-ID: <CsEJx0.L3@tfs.com>
Organization: TRW Financial Systems, Oakland, CA
References: <2uacoc$gfi@reuter.cse.ogi.edu> <2v79ig$s8u@masala.cc.uh.edu> <2v7tf4$ctj@mojo.eng.umd.edu> <2v87c0$6vo@masala.cc.uh.edu>
Date: Mon, 4 Jul 1994 06:12:36 GMT
Lines: 55
In article <2v87c0$6vo@masala.cc.uh.edu>,
Woody Jin <wjin@moocow.cs.uh.edu> wrote:
>
>However, in Unix, a program does not reside in consecutive pages, they
>are all scattered around the physical memory.
[....]
>While the above story is not realistic, it is typical that similar story
>happens very often. We may easily know this since direct mapped cache (DMC)
>can't do LRU. For example,
[....]
>the trn's page, which the tcsh's page was resideing, and when I exit from tcsh,
>the DMC will again fault to bring in the trn's page. The atrocious fact is that
>all these happen, even though there is a lot of free space available in cache.
>
[...]
>One problem is that it is very difficult to expect the hit ratio of cache in
>muti-tasking OS.
>The only way is to compare the performance by running various applications.
>
I think you are confusing the buffer cache with the ram cache.
The Ram cache is not page aligned or even page based.
it caches memory locations on a much smaller granularity,
and cares not about the relative locations of pages.
While it is true that two processes could easily be running with
active code paths running to the same cache lines, with a large (256k)
cache and few programs running, this doesn't happen that often. Anyway
caches are used mostly to speed up looped code, in which case the
scale of loop times is so small compared to the scale of the scheduling
quanta, that even thoug a cache line may be flushed out by a competing process
it is still effectlive in assiting Both processes because it assists
all but the first loop on each sheduling burst.
running with rm cache turned off on a 486DX50 will
result in a 3 to 5 times reduction in speed (from experience).
On a DX2 or DX3 machine I would expect the result to be worse.
whether increasing the cache size from 256K to 512K has much effect
depends on the application and the system concerned..
more complicated cache systems have been developed implimenting
such features as a 'LRU' effect etc.
they offer improvements but the biggest improvement comes with having
any cache Vs having NO cache.
julian
+----------------------------------+ ______ _ __
| __--_|\ Julian Elischer | \ U \/ / On assignment
| / \ julian@tfs.com +------>x USA \ in a very strange
| ( OZ ) 300 lakeside Dr. oakland CA. \___ ___ | country !
+- X_.---._/ USA+(510) 645-3137(wk) \_/ \\
v