“Tony” <firstname.lastname@example.org> wrote in message
On Fri, 12 Nov 2004 11:59:47 -0500, Mario Charest
email@example.com> > wrote:
Well nothing bad is going to happen if the CPU is busy 100% > > It’s
more about process priority than CPU usage.
Does that answer your question?
My question was induced by “Net.ether509 and dhcp.client” trouble I had
recently. There I saw my hardware’s IRQ being dropped or not serviced in
How did you come to the conclusion your IRQ were dropped. There is a
difference between an IRQ being dropped and the process not being able to
service a proxy sent by the IRQ.
The only thing that can cause IRQ being dropped is interrupt being disabled
IRQ of higher priority lasting too long. This is NOT directly connected to
In fact CPU usage as reported by sac or sysmon, does not take account time
spent in interrupt.
May I think that as long the has at least ~10% of CPU - I’m safe no
matter the priority of the CPU-hog process?
Again it depends on your definition of safe. You can’t say “no matter the
that is exactly what matters.
Or, this does not warrant that IRQs will be serviced in time, if reaction
should follow not on the next timeslice but in, say, lower tens of
mircoseconds? I’ve seen Proc32 consuming ~90% of CPU…
Proc32 on it’s own doesn’t consume CPU (aside for timer management), it
always perform a tasks upon request.
What is the “worst case” figure for CPU being busy with priority 30 and
still serving IRQs fast?
I don’t think that is a number you can predict. It depends on what the
process at priority 30 does (that includes the kernel),
if it doesn’t disable interrupt then ISR will be services. IRQ are higher
priority then software priority.
Plus you can’t talk about percentage, because CPU speed is important. 10% of
2GIG cpu is not the same as 10% of a 66Mzh
The 66Mzh cpu may need 70% of it’s cpu to handle interrupts (ISR itself and
work done by process) while a 2Gig may only need 1%.