Of course there is - I just thought NUMA was about RAM topology, not caches? I do see that the Windows NUMA APIs include cache information... which makes sense

NUMA:

So far, it appears only Windows includes cache topology in NUMA. Yet, it is important to understand shared cache from a performance standpoint.

I made a Driver that works also on multi-processors Computers with Windows 7.

It uses the imported kernel api KeIpiGenericCall to execute a broadcast function automatically in every CPU in the same time.
You can choose all CPU or a specific CPU for the execution.
There is a procedure to serialize the CPU executions (exclusive mode)
It has also the undo operation.

It is simple and customizable. Read the source for more details
Also there's the Fasm DDK 2 (new relase) inside the pack

The 64 bit version is in progress....

Sorry, i've forgot 4 brakets because i've re-edit the source for compatibility with the FASM Board. (what does it mean? )

The ZIP package is updated and works perfectly.

Hallo Pirata,
first of all, thanks for the clear good code. I have a question (i am like a baby
in this context) , from the comment in the source file

It is to say, although for example the rdtsc is "per se" a EDIT: NOT serializing instruction, i could (or i will be able on x64) execute 2 rdtsc instructions at ring0 and measure the time elapsed in only one of my Yorkfield 4 cores ?
Have you an userland template (load/unload driver) to test it ?

Keep it up so !

Cherrs
hopcode

I thought the TSC was never guaranteed to be the same counter on all cores. Although some current CPUs only physically implement one counter that is not guaranteed to be true for all systems. Reading the TSC for timing is fraught with pitfalls unless one takes the proper actions to ensure various conditions are properly met.

I can easly program that driver in x86 - multi-processors:
The x64 one... you have to wait for me, because i'm exercising in Multi-processors and the x64 platform programming.
i prefered change my old single-core 32bit computer with one 64bit dual-core, instead of using virtual machines.

IMPORTANT!
I've programmed a similar program but it execute 3 RDTSC:

Correction is useful for slow or crappy processors that elapse time for RDTSC execution and also all operations needed to store value or others.
Teorically "correction" is equal to 0, but who knows?

You can make a driver that disable the Time Stamp Disable flag, so you can execute RDTSC in ring3 directly every time you want until PC reset.
Sometimes INTERRUPTIONS and context switches can invalidate results.
Time Stamp Disable flag is the third bit in the CR4 register.


If you get trouble, i can suggest you another way (my preferred) witout interruptions or problems:

The Driver must hook SYSENTER when loading and relase it when unloading,
also it has to preserve the original pointer to redirect normal syscalls to kernel.
You should use a "Broadcast Worker" similar driver and set the TARGET_CPU value, so the driver will function only in a specific core.

The hooked Sysenter function (in the driver) has only to check if a system call have the EDX (or RDX) register = 0.
If this register is 0 then there's a special syscall (from the interfacing program), because the KiFastSystemCall function always store a value in that register.

When a special syscall is acquired, driver will store the usermode values (read below) and then it is redirected into OUR function. (in this case to read the time stamp counter two times... or all operations what you want!)
You should RAISE THE IRQL to prevent context switch.
I prefer raise it in IPI_LEVEL so my core is isolated from the other/s.

OUR function can:
start counting with the first special syscall and end counting with another syscall.
Also you have consider (subtract) the time spent for system call, raising irql, inverse functions and so on....
Same system is implemented in my new version of "NATIVE API INTERCEPTOR".

After that, the driver creates the stack for an "Artificial Interrupt" and then uses IRET to go back the SYSENTER.

Code:

 FastReturnFromDriver:
    PUSHD 23h ; usermode stack segment
    PUSHD [usermode_stack_pointer] ; provided by the interfacing program
    PUSHD [usermode_flags] ; provided by the interfacing program
    PUSHD 1Bh ; usermode code segment
    PUSHD [usermode_eip] ; provided by the interfacing program
    IRETD    

The RDTSC values will be in general registers like EAX.
Execution in a single core give more precision.
Remember to measure all the optional functions time (as various corrections) and subtract all of them to the main delta execution time.
result: VERY HIGH PRECISELY VALUE

The INTERFACING PROGRAM has only to put its variables into general registers, set EDX = 0 and then make a SYSCALL.
Don't forget to set ITS AFFINITY PROCESS like the hooked CPU core!

Code:

;  Calling our driver using my personal routine
DerekFastDriverCall:
    PUSHFD
    POP EAX ; we save the EFLAGS
    MOV EDI, ESP ; we save the stack
    XOR EDX,EDX ; the "special syscall"
    MOV ESI, .Return ; return eip
    SYSCALL ; go to driver
    .Return: NOP
    RET    

The driver will provide storage of these values to return in usermode
You can see my old interface driver example in this board

I hope all informations will be usefull for you.
wait for me and i'll post for you the x64 driver

From Wikipedia:

With the advent of multi-core/hyperthreaded CPUs, systems with multiple CPUs, and "hibernating" operating systems, the TSC cannot be relied on to provide accurate results. The issue has two components: rate of tick and whether all cores (processors) have identical values in their time-keeping registers. There is no promise that the timestamp counters of multiple CPUs on a single motherboard will be synchronized. In such cases, programmers can only get reliable results by locking their code to a single CPU.

What a perfect post?