Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!shelby!Portia!Jessica!rpeck From: rpeck@Jessica.stanford.edu (Raymond Peck) Newsgroups: comp.arch Subject: Re: Context switch tasks Message-ID: <517@Portia.Stanford.EDU> Date: 28 Feb 89 01:11:12 GMT References: <788@atanasoff.cs.iastate.edu> <497@pyuxf.UUCP> Sender: USENET News System Reply-To: rpeck@Jessica.stanford.edu (Raymond Peck) Organization: Stanford University Lines: 36 >In article <788@atanasoff.cs.iastate.edu>, hascall@atanasoff.cs.iastate.edu (John Hascall) writes: >> A couple of days ago I posted a question about saving/restoring >> registers during context switch. >> >> A couple of people sent me mail saying that register/save restore >> was a very small part of the time taken by a context switch. One >> person claimed about 1%! >> >> What all are you people doing during context switch??? >> And are they things which are required by the architecture of the >> machine or by a particular OS? >> >> Tasks done at in response to reschedule interrupt (as I see it): >> [ obvious context-switch steps deleted ] I think it's interesting that people define context-switch time as the time it takes to do the reg saves, etc. There's a whole other issue that is usually ignored, and is only hinted at in Mr. Hascall's posting. That is: cache flush. Most architectures today do not use PIDs in the cache tags. This, of course, requires all the caches to be flushed (invalidated) upon context switch. So every time you do a switch, you run like molasses until your cache becomes warm again. I think this is *really* where you get hit, not in how sloppily you save the registers. Cold cache misses generate a lot more memory references than register save/restore (unless you have register windows. . . ;-) (*****************************************************************************) "Submarines are lurking in my foggy ceiling/ they keep me sleepless at night" "Read some Kerouac and it put me on the track to burn a little brighter now" (*****************************************************************************)