Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2303 > unrolled thread

Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows ?

Back to article view | Back to comp.arch

Contents

  Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? MitchAlsup <MitchAlsup@aol.com> - 2011-07-01 07:45 -0700
    Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? vandys@vsta.org - 2011-07-01 17:03 +0000
    Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-01 20:10 +0000
      Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-07-02 09:29 +0200
        Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? Andrew Reilly <areilly---@bigpond.net.au> - 2011-07-02 13:37 +0000
    Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-03 09:52 +0200
      Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows  ? "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-07-03 09:58 +0200

#2303 — Re: Do x86 or arm processors have "interrupt overload protection" or maybe windows ?

x86 enters an uninteruptable state at the transfer of control to the interupt handler. So until the interrupt handler (or OS) reenables the interrupt (or you return from interrupt) it will not 'take' another one.

So, if you are having interrupt throughput issues, change the interrupt handler to just enque a unit of work and schedule the non-interrupt handler to do the work (then return from interrupt). This way you can keep the actual interrupt disabled time to a minimum.

[toc] | [next] | [standalone]

#2305

MitchAlsup <MitchAlsup@aol.com> wrote:
> x86 enters an uninteruptable state at the transfer of control to the
> interupt handler. So until the interrupt handler (or OS) reenables the
> interrupt (or you return from interrupt) it will not 'take' another one.

Note that if you have a preemptable kernel, page faults also have to be set
up to be an "interrupt" exception with this auto-masking.  Otherwise you can
take a hardware interrupt in the window from the exception until you read
CR2, have that interrupt dispatch a higher priority task (or otherwise cause
a page fault), and find CR2's value changed by the time you switch back to
the preempted page fault code path.

But Mitch is quite correct, the tendency is to do too much in the interrupt
handler path.  RSX-11, for instance, had solid guidelines on how much time to
spend in there, and also excellent facilities for arranging further
processing out of the front-line interrupt handler.

-- 
Andy Valencia
Home page: http://www.vsta.org/andy/
To contact me: http://www.vsta.org/contact/andy.html

[toc] | [prev] | [next] | [standalone]

#2306

Also, at least an x86 has a *stack*, so it's luckier than a 360 in the
event of an interrupt.

John Savard
http://www.quadibloc.com/index.html

[toc] | [prev] | [next] | [standalone]

#2313

John Savard wrote:
> Also, at least an x86 has a *stack*, so it's luckier than a 360 in the
> event of an interrupt.

Not anymore:

Current x64 cpus with SSE++ can have a K or more of architecture-visible 
processor task state.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#2317

On Sat, 02 Jul 2011 09:29:18 +0200, Terje Mathisen wrote:

> John Savard wrote:
>> Also, at least an x86 has a *stack*, so it's luckier than a 360 in the
>> event of an interrupt.
> 
> Not anymore:
> 
> Current x64 cpus with SSE++ can have a K or more of architecture-visible
> processor task state.

True, but a FLIH only needs to save what it will use, which is why there 
are rules against using floating point in such situations.  And when your 
interrupt makes a higher-priority task runnable and you actually have to 
switch tasks, there is probably a fair bit of state even beyond the 
architecture-visible register state that needs to be saved/copied.  Just 
as well there are lots of cores now, all with their own state, mostly 
sitting around waiting for something to do...

[No, I mostly don't get to pay with those, yet.  Just guessing.]

Cheers,

-- 
Andrew

[toc] | [prev] | [next] | [standalone]

#2322

It doesn't really matter if the interrupt time takes long or short.

If it takes long like 5 years, the system will freeze for 5 years.

If it takes short like 1 year, but there are 5 interrupts per 5 years (one 
average one per year), then the system will still freeze 5 years.

It's also not about how long the interrupt handler itself takes, it's also 
about how much cpu time is associated with handling the data generated from 
the interrupt.

Windows 95 computers are pretty easily dos-able via network cards.

Perhaps this "network" attack possibility still existing in windows 
xp/windows seven !?

Somehow the OS and perhaps the hardware should be able to "throttle" the 
ammount of cpu time spent on interrupt handling be it inside or outside the 
interrupt itself ;)

Bye,
  Skybuck. 

[toc] | [prev] | [next] | [standalone]

#2323

One idea could be to use "interrupt clock cycle tracking".

The CPU knows how many clock cycles it has available per second.

The operating system can also gather this information.

The operating system could set a "maximum ammount of clock cycles" that can 
be spent for interrupt handlers.

The CPU adds or subtracts the "clock cycle interval" for interrupts to/from 
a counter.

When this counter reaches zero, no further interrupts are allowed, this 
means full cpu cycles available for the rest of the system.

However still could still kill the system if all cycles are spent on the 
network side of things.

So perhaps a counter per hardware device/interrupt type would probably be 
nice.

This way the mouse and other devices keep working and only the network 
card/side of things gets disabled until the counter is fed with new cycles 
to burn.

Each second the cpu adds cycles to the counter which may be burned on 
interrupt handling.

The counter is also cut off at a maximum to not overflow it.

The maximum can be set by the operating system per interrupt type.

Bye,
  Skybuck. 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web