🚀 go-pugleaf

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).
  Perhaps there are issues that I'm missing; later on in your post you
mention real-time systems, with which I have no experience.  Is there
something about real-time systems that necessitates flushing the entire
cache with a context switch?




-- 
Bill Moyer <ttk@rahul.net>