Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!usc!zaphod.mps.ohio-state.edu!mips!winchester!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: Context switching on RISC chips Message-ID: <34043@mips.mips.COM> Date: 2 Jan 90 19:26:02 GMT References: <3167@iitmax.IIT.EDU> Sender: news@mips.COM Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Inc. Lines: 67 In article <3167@iitmax.IIT.EDU> ed@iitmax.iit.edu (Ed Federmeyer) writes: >One of the things that seems to characterize RISC chips is the relatively >large number of registers. This makes me wonder what happens during a >context switch. After all, moving 256 (or more) registers to memory, and >then another 256 (or more!) back in for each context switch seems like an >awfull lot of overhead. I can think of a few ways around this: It is good to avoid over-generalizing: a) Many RISCs do not have as many registers, i.e. in approximate numbers of 32-bit registers, ignoring system registers: 88K: 32 MIPS & HP PA: 64 b) The registers are only one part of the state / cost for context switching. Others include: system and internal registers (consider the amount of state pushed on stack of 68K on some exceptions) MMU/TLBs [some designs require state save if more than N processes; others pay the cost incrementally, but some cost is paid, sometime. cache structure, especially if flushes are needed, as in i860 c) In fact, in OS's like UNIX, moderate changes in numbers of registers have fairly minimal effects on context-switching time, compared with the above issues, plus even more important: the OS structure, and its design tradeoffs. In particular, the definition of "Context switch" is pretty fuzzy, because it really matters how you measure it. Is it: time to save/restore registers? time to save/restore entire state? time to do all of that, plus the OS scheduling code? measured by switching between 2 processes, or between N? d) Amount of state changed is likely to be more important in such operating systems as: 1) Switching machine OSs, which have large numbers of processes that execute for fairly short periods of time. 2) Real-time operating systems, especially at the "hard" edge, where guaranteed predictability is required. (Mechanisms that increase thruput for somethings often increase the variability.) Given all of this, it's sometimes pretty hard to make comparisons, except by benchmarking an entire hardware+operating system combination, ideally with the same OS. I have a tiny piece of data, from which large conclusions should not be drawn, but which is useful. JMI Software Consultants has a fairly portable real-time kernel called C Executive (TM), and they publish some numbers on different environments. Here are times in microseconds for context-switch, version 2.3, published 10/89: CPU R2000 68020 29000 SPARC System M/120 FORCE AMD Sun-4/2xx MHz 16.7 25 20 16.7 C Compiler MIPS Whitesmiths MetaWare Sun Cntxt Switch, microseconds 10 17 29 20 ------------- Now, that's all that I know. I don't know what the board designs are for the 68020 and 29000, and I have no idea of the internal structure of the C Executive and how it matches the different chips; I have no idea how they measure context-switching, just that it's consistent. It is pretty clear that there is at least a gross correlation with number of registers here, but that's about all. -- -john mashey DISCLAIMER: 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