Developing for multi core CPUs

Hi,

i wondered wether it is possible to determine on which CPU a driver is
loaded on a multi core system. The intention behind this is that i want to
have a whole CPU on my own to get highest performance and avoid interfering
with the rest of the system.

Regards
Max

Don
Mon Jun 04 11:09:05 CDT 2007

Drivers are not loaded on a core, a core is just another cpu in a
multi-processor system. Your driver needs to be able to run on all
processors concurrently, the system will do the scheduling.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"Max Mayer" <mayer_max@web.de> wrote in message
news:badtouwcvnud.cxnkdmeueob7$.dlg@40tude.net...
> Hi,
>
> i wondered wether it is possible to determine on which CPU a driver is
> loaded on a multi core system. The intention behind this is that i want
> to
> have a whole CPU on my own to get highest performance and avoid
> interfering
> with the rest of the system.
>
> Regards
> Max

Ben
Mon Jun 04 11:24:25 CDT 2007


"Max Mayer" <mayer_max@web.de> wrote in message
news:badtouwcvnud.cxnkdmeueob7$.dlg@40tude.net...
> Hi,
>
> i wondered wether it is possible to determine on which CPU a driver is
> loaded on a multi core system. The intention behind this is that i want to
> have a whole CPU on my own to get highest performance and avoid
> interfering
> with the rest of the system.
>

Driver code can run from any CPU.

If you want to monopolize a CPU, that can probably be done from the user
application by setting a realtime priority and affinity. It can then use
I/O requests and IOCTLs to run driver code as desired.

I hope that you are only wanting to do this for a particular fixed-function
system, not a peripheral device. Claiming an entire CPU is entirely
unreasonable unless you control everything else executing on the system.

> Regards
> Max

Maxim
Mon Jun 04 13:05:18 CDT 2007

Why do you think that excluding the OS's scheduler will give you more
performance?

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

"Max Mayer" <mayer_max@web.de> wrote in message
news:badtouwcvnud.cxnkdmeueob7$.dlg@40tude.net...
> Hi,
>
> i wondered wether it is possible to determine on which CPU a driver is
> loaded on a multi core system. The intention behind this is that i want to
> have a whole CPU on my own to get highest performance and avoid interfering
> with the rest of the system.
>
> Regards
> Max

Max
Mon Jun 04 14:32:27 CDT 2007

Am Mon, 4 Jun 2007 22:05:18 +0400 schrieb Maxim S. Shatskih:

> Why do you think that excluding the OS's scheduler will give you more
> performance?

I want to do fast data acquisition in real-time which requires minimal
interrupt latency. From that point of view the OS's scheduler is a
non-deterministic black box. That's why i want to avoid it.


Max

Don
Mon Jun 04 14:46:40 CDT 2007

Then get a real time OS. While you can force your driver to run on one
core, you cannot stop everything else from using that core also. Also,
running on a single core is not going to improve your interrupt latency.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply

"Max Mayer" <mayer_max@web.de> wrote in message
news:1m1t8z9oslwqy.j63qw2nx3a4x$.dlg@40tude.net...
> Am Mon, 4 Jun 2007 22:05:18 +0400 schrieb Maxim S. Shatskih:
>
>> Why do you think that excluding the OS's scheduler will give you
>> more
>> performance?
>
> I want to do fast data acquisition in real-time which requires minimal
> interrupt latency. From that point of view the OS's scheduler is a
> non-deterministic black box. That's why i want to avoid it.
>
>
> Max

Mark
Mon Jun 04 15:19:37 CDT 2007

Ben Voigt [C++ MVP] wrote:
> "Max Mayer" <mayer_max@web.de> wrote in message
> news:badtouwcvnud.cxnkdmeueob7$.dlg@40tude.net...
>> Hi,
>>
>> i wondered wether it is possible to determine on which CPU a driver is
>> loaded on a multi core system. The intention behind this is that i want to
>> have a whole CPU on my own to get highest performance and avoid
>> interfering
>> with the rest of the system.
>>
>
> Driver code can run from any CPU.
>
> If you want to monopolize a CPU, that can probably be done from the user
> application by setting a realtime priority and affinity. It can then use
> I/O requests and IOCTLs to run driver code as desired.
>
> I hope that you are only wanting to do this for a particular fixed-function
> system, not a peripheral device. Claiming an entire CPU is entirely
> unreasonable unless you control everything else executing on the system.
>
>> Regards
>> Max
>
>

And you can also force your interrupt side (both isr and dpc) to a
specific logical cpu as well. See IoConnectInterrupt's
ProcessorEnableMask and see vista's support for registry based interrupt
affinity policy and see KeSetTargetProcessorDpc. Admonitions about all
of this being a possibly completely stupid idea are noted.

Ben
Mon Jun 04 15:35:35 CDT 2007


"Don Burn" <burn@stopspam.windrvr.com> wrote in message
news:%23v8BiEupHHA.4112@TK2MSFTNGP04.phx.gbl...
> Then get a real time OS. While you can force your driver to run on one
> core, you cannot stop everything else from using that core also. Also,
> running on a single core is not going to improve your interrupt latency.

Although it would be theoretically possible to use the single processor HAL,
and initialize the second processor yourself. Then no OS code would ever
run on that processor (and you'd better not call any OS functions from there
either... grabbing your data, RTDSC, and copy into shared memory only). And
I can't see how you could possibly do anything useful due to bus ownership
issues, if the OS is using the PCI bus when you want it even having your own
CPU won't help. I guess that is what Don said, although I first read
something else into his statement.

>
>
> --
> Don Burn (MVP, Windows DDK)
> Windows 2k/XP/2k3 Filesystem and Driver Consulting
> Website: http://www.windrvr.com
> Blog: http://msmvps.com/blogs/WinDrvr
> Remove StopSpam to reply
>
> "Max Mayer" <mayer_max@web.de> wrote in message
> news:1m1t8z9oslwqy.j63qw2nx3a4x$.dlg@40tude.net...
>> Am Mon, 4 Jun 2007 22:05:18 +0400 schrieb Maxim S. Shatskih:
>>
>>> Why do you think that excluding the OS's scheduler will give you
>>> more
>>> performance?
>>
>> I want to do fast data acquisition in real-time which requires minimal
>> interrupt latency. From that point of view the OS's scheduler is a
>> non-deterministic black box. That's why i want to avoid it.
>>
>>
>> Max
>
>

Maxim
Mon Jun 04 17:05:03 CDT 2007

> I want to do fast data acquisition in real-time which requires minimal
> interrupt latency. From that point of view the OS's scheduler is a
> non-deterministic black box. That's why i want to avoid it.

_Interrupts_ do not go thru scheduler, and you can tie them to a CPU using
Affinity parameter to IoConnectInterrupt.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

Tim
Tue Jun 05 01:29:02 CDT 2007

Max Mayer <mayer_max@web.de> wrote:

>Am Mon, 4 Jun 2007 22:05:18 +0400 schrieb Maxim S. Shatskih:
>
>> Why do you think that excluding the OS's scheduler will give you more
>> performance?
>
>I want to do fast data acquisition in real-time which requires minimal
>interrupt latency. From that point of view the OS's scheduler is a
>non-deterministic black box. That's why i want to avoid it.

This shows quite a serious misunderstanding of the PC architecture. Let's
say that you COULD lock your driver into one CPU. What do you think that
CPU is going to be doing when your driver finishes a task? Further, when
an interrupt comes in, the CPU is going to switch to the system's interrupt
handler, whether your driver is in the CPU or not.

The operating system is much smarter about knowing how to balance the load
among CPUs than you are. Anything you do is going to reduce the overall
performance.
--
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.