🚀 go-pugleaf

Nick Maclaren (nmm1@cus.cam.ac.uk) wrote:
: 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

There seems to be a little confusion here about the cache and the instruction 
pipeline and the multiple executions units.  First off, there is but a single
user interrupt, so the interrupt must be decoded in software.  Second, the 
interrupts usually perform a sync instruction and an eieio instruction to 
force instruction retirement from all of the execution units and any out-of-
order processing to get the registers into a known state.  Now a new context
can be generated before the interrupt processing itself can be done.  The 
context switch involves creating a stack frame, possible a new stack pointer,
saving the registers used by the interrupt, and then branching to the interrupt 
decode section.  The RISC processors are all a bit complicated about this, 
especially superscalar superpipelined ones like the PPC family.

Flushing the cache is not necessary - the hardware takes care of that nicely.

--
Larry Diehr
IMHO - I _am_ right :-)