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

Extremely apologise for jumping into this discussion,

Why should someone apologize for joining a discussion???? After all,
this is what NGs are for, in the first place.....

how then the Process Explorer displays time percentage for interrupts and dpc ?

As I said, from the system management tool's perspective, the term 'CPU
load' means system and user threads vs idle thread - interrupts and DPC
are not involved here, so that they cannot affect CPU load, as far as
system management tools are concerned. I know it sounds pretty bizzare,
so that the best thing to do is to look at the example.

If CPU load, displayed by the Process explorer, is zero, it does not
mean that CPU stopped dead in its tracks, does it??? The only thing it
means is that CPU had nothing to do throughout the refresh period (in
Process Explorer the minimal one is 0.5 sec), so that it had been
dispatching its idle thread. However, throughout this perios time was
being updated and screen was being refreshed, which means interrupts
and DPCs had been processed (ISR normally quesus a DPC)

Sounds like a contradiction? Not at all. Interrupts and DPCs are
processed in context of the arbitrary thread, i.e. currently running
one. Once idle thread was the only one that ran throughout the refresh
period, everything had been processed in
its context, so that CPU load appears to be zero.

Mark and Bruce found, in my opinion, just an excellent solution to this
dilemma - they presented interrupts and DPCs as artificial processes.
As a result, they killed two birds with one stone - first, we are able
to see the percentage of time that CPU has spent processing interrupts
and DPCs, and, second, the info about CPU time of all other processes
is more
accurate, because the time spent on processing interrupts and DPCs has
been excluded....

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,

This also looks as overstatement.

Not at all....

Even if a driver does not handle interrupts, it nevertheless can do a lot of work at dispatch,

It does not really matter if driver processes interrupts - it just
cannot afford to do "a lot of work" at DISPATCH_LEVEL, let alone at
DIRQL. If it attempts to do "a lot of work" at elevated IRQL, it
will eventually bring the system down, or at least make it unusable.

Therefore, if driver needs to do something more or less time-consuming,
it has to queue a work item, which will be processed at PASSIVE_LEVEL,
and, at this point, it can can afford some inefficiency. As I said, at
PASSIVE_LEVEL
this inefficiency alone would not bring the system down, but the
overall system performance degradation may get noticeable....

Anton Bassov



Pavel A. wrote:
"anton bassov" <soviet_bloke@xxxxxxxxxxx> wrote in message news:1165360492.928427.276470@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

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.

Extremely apologise for jumping into this discussion, but
how then the Process Explorer displays time percentage
for interrupts and dpc ?


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,

This also looks as overstatement. Even if a driver does not
handle interrupts, it nevertheless can do a lot of work at dispatch,
just because this is simple (WDM, USB and so on)

Regards,
--PA

.

Relevant Pages

  • Re: DPC has high latency only with SMP
    ... interrupts and the dpc are mostly queued on the cpu 0 (cpu 0 handles ... almost about 1000 dpc and interrupts per second, ... I'm setting up a dual processor from another vendor, ...
    (microsoft.public.development.device.drivers)
  • Re: [parisc-linux] [patch 15/23] Add cmpxchg_local to parisc
    ... non-SMP-safe counter that protects updates against interrupts. ... could be vastely used in the kernel. ... "Local atomic operations only guarantee variable modification atomicity ... that only one CPU writes to the local_t data. ...
    (Linux-Kernel)
  • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
    ... Thats what I'm doing at the moment. ... unicast interrupts delivered accross the ht bus to a single cpu, ... that that broadcast bit was set. ...
    (Linux-Kernel)
  • Re: how can i disble irq15 through C/assembly programming.
    ... Well, these machines do not run Windows, do they? ... This condition is enforced by the CPU itself, ... interrupts as a whole, but the OP wants to disable interrupts only for ... disable interrupts on CPU Y..... ...
    (microsoft.public.win32.programmer.kernel)
  • [rfc] direct IO submission and completion scalability issues
    ... i.e, as a new request comes in, the request get directly submitted to the ... IO controller on the same cpu that the request originates. ... likely happens on a different cpu which is processing interrupts. ... Quick and dirty prototype patchfor this io migration ...
    (Linux-Kernel)