🚀 go-pugleaf

In article <42cv5o$9v4@bug.rahul.net>, Bill Moyer <ttk@rahul.net> writes:
|> In article <tonyn-0109950144230001@tonyn.tiac.net>, tonyn@tiac.net says...
|> >
|> >On any CPU, interrupt processing requires a context switch (also required
|> >for preemption and system services).  In the old days, this required
|> >simply the amount of time the CPU required to start the interrupt (and
|> >finish it later) plus the instructions in the interrupt handler.
|> >
|> >Nowadays the penalty for an interrupt is much greater, because of
|> >processor caches (or rather, fast processors but memory at the same speed
|> >as before).  The context switch now requires flushing the cache, so the
|> >processor will run slowly for a while as instructions are fetched from
|> >"real memory".  
|> 
|>   Is this an issue?  I don't have much experience beyond the 80x86 
|> family of processors, but I do know that the caches on these processors
|> cache physical memory.  There's no reason to do a cache flush with every
|> context switch.  The only time you really need to do something like this 
|> is when a page is targeted by a peripheral device for DMA.  The TLB does
|> need to be invalidated with a context switch, but this is an O(1) opera-
|> tion that can happen in parallel with other processor activities, and it
|> only marginally impacts performance (as memory metadata is fetched from
|> memory and the information reflected in the TLB).

Some systems attach parts of the cache to address spaces, but not
many.  I agree with you that the only thing that is usually flushed
is the TLB, but I disagree that it is a marginal problem.  I have
seen several workstations run like a drain when running X, simply
because of the lack of TLB slots.

If you want a REAL mind-reset, look at MVS/ESA's 48- to 64-bit design.
Pageable TLBs :-)


Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679