Re: program runs almost twice as slow on 2 CPU machine when 1 CPU

Arnaud,

Actually, it would be a good idea for you to learn what interrupts are

Ah... I see that Mr Anton is always sooooooo respectfull and polite.... Nice

I am afraid you just got it wrong......

I did not mean to offend you in any possible way - the statement that
you made just made me believe that you don't know that much about
interrupts, so that it might be a good idea for you to learn a bit
about them. What is wrong with the advice to educate yourself??? In
fact, I don't know about your objectives, but I participate in the NG
mainly for the purpose of educating myself....

In any case, if you got offended somehow, I am really sorry for
that......

The very idea of interrupts is completely irrelevant here - they don't
affect CPU load, as far as system management tools are concerned.
Actually, if CPU load is, say, 10%, it means that CPU dispatches its
idle thread 90% of the time and system/user threads 10% of the time,
i.e. it has nothing to do 90% of the time, so that it dispatches its
idle thread.
Therefore, if CPU load is high, it means that system/user threads keep
it busy. Once interrupt can get raised at any time, regardless of the
thread that currently runs on the target CPU, they cannot affect CPU
load, as far as system management tools are concerned.

When I said "interrupts", it was a generic term meaning both ISRs and
DPCs....

As far as applications are concerned, the story with DPCs is more or
less the same. In general, whenever your application runs too slowly
for some external reason, the code that runs at IRQL >= DPC level is
the last thing that may be suspected as a possible culprit.....

I can show you a poorly written device driver that, when talking with it's
hardware, take a significant amount of processor power in those kernel mode
routines....

Things may happen this way, but it has nothing to do with interrupts or
DPCs.....

In fact, there are not that many drivers that actually deal with
interrupts - only port and miniport drivers do it. All other drivers
just submit their requests, and pass them down the stack. They run at
IRQL < DPC level most of the time, and, at this IRQL, theoretically
they can afford to be pretty inefficient - as long as IRQL is low,
this ineficiency alone would not bring the system down, although
overall system performance degradation may be noticeable. Apparently,
you were just "lucky" enough to come across such "sample"

Anton Bassov


Arnaud Debaene wrote:
"anton bassov" <soviet_bloke@xxxxxxxxxxx> a écrit dans le message de news:
1165297825.145544.236620@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Use Process Explorer (www.sysinternals.com) to see who is taking
processor
time. I would suspect interrupts...

Actually, it would be a good idea for you to learn what interrupts are

Ah... I see that Mr Anton is always sooooooo respectfull and polite.... Nice

When I said "interrupts", it was a generic term meaning both ISRs and
DPCs.... It was probably a bold guess of my part in the case of the OP, but
I can show you a poorly written device driver that, when talking with it's
hardware, take a significant amount of processor power in those kernel mode
routines....

Arnaud
MVP - VC

.

Relevant Pages