🚀 go-pugleaf

In article <24958@amdcad.AMD.COM> rpw3@amdcad.UUCP (Rob Warnock) writes:
>In article <39485@oliveb.olivetti.com> (Lance Berc) writes:
>+---------------
>| Intel estimates that at 33MHz flushing the D-cache takes on average
>| 30usec (30% - 50% dirty) and 60usec worst case. I believe that these
>| numbers assume no wait-state memory (fastest possible 5 2 2 2 CPU to
>+---------------
>
>Similarly, because of the very large register file, the Am29000 appears
>at first to have a problem with full context switching (*not* system calls...

>I just don't see 20-50 VUPS type of systems needing to do tens of thousands
>of full context switches per second, at least not in general-purpose
>timesharing...

A lightning look at busy machines around here showed 60-120 cs/sec.
If it only takes 30-60 microsec, that's 1.8-7.2 millisec / sec,
or a little less than half a percent.
Now, that's the easy part.
-----
The hard parts are: 1) figuring out how often you must flush the caches
because you change a mapping in the kernel [maybe the Sun folks can say
something on this; I recall them talking about tuning to avoid unnecessary
flushings in virtual caches], and 2) figuring out what the aggregate
cache miss rate impact is of flushing the caches more often.
(I have no idea, and it surely is load-dependent, and there's probably
some nice papers sitting around to be done.)

The modest size of on-chip caches makes this less detrimental,
in terms of what you're losing by flushing them.  As they get bigger,
it will get more noticable, especially for OS performance itself,
which REALLY likes big caches, since it has bad locality.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	{ames,decwrl,prls,pyramid}!mips!mash  OR  mash@mips.com
DDD:  	408-991-0253 or 408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086