Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!ames!amdcad!smeeta
From: smeeta@amdcad.UUCP
Newsgroups: comp.arch
Subject: Re: Am29000 and MIPS
Message-ID: <15273@amdcad.UUCP>
Date: Mon, 23-Mar-87 15:01:29 EST
Article-I.D.: amdcad.15273
Posted: Mon Mar 23 15:01:29 1987
Date-Received: Wed, 25-Mar-87 04:20:14 EST
References: <15192@amdcad.UUCP> <1423@husc6.UUCP> <15243@sun.uucp> <218@winchester.mips.UUCP>
Distribution: world
Organization: AMDCAD, Sunnyvale, CA
Lines: 28
Summary: simulation of context switching

In article <218@winchester.mips.UUCP>, mash@mips.UUCP (John Mashey) writes:
> 
> How often were caches swept in the simulations to account for context-switch,
> clocks [running under unix, you can lose several % to the fact that
> clock interrupts execute a bunch of code], system-call overhead, etc?
> 
The simulations done for benchmarking the Am29000 did not explicitly sweep
the caches to account for context-switches in between simulation runs. However,
most of the simulations performed  on the Am29000 executed in 60,000 cycles or 
less. So the cost for a cold start for filling caches and TLB entries is 
amortized over the relatively short runtime. 

For example, we modified Dhrystone 1.1 to run for 50 iterations instead of the 
500,000 iterations (standard). This made the simulation runtime more
manageable and also had the effect of a full "cache sweep" every 2.4 msec.

For the longer running benchmarks one should take into account the context-
switch time. However, we have not yet determined the best model for simulating
the effect of a multiprogramming environment on caches, without actually 
implementing the full OS kernel. 


Smeeta Gupta
Tim Olson

Strategic Development for Processor Products.

Advanced Micro Devices, Sunnyvale,Ca.