>
Another contract change that was introduced in server 2008 R2 was
greater than
64 proc support. This has 2 visible changes
- MAXIMUM_PROCESSORS is now meaningless
- If a driver was using the current processor’s index in the affinity
mask as
an index into their own data structure (such as an array bounded which
has
MAXIMUM_PROCESSORS elements), while the index will never exceed
MAXIMUM_PROCESSORS so you will not go off the end of the array, 2
concurrent
threads of execution (be it dispatch routines, DPCs, whatever) can
both have
the same index but be in different processor groups, thus invalidating
the
assumption that the index can be used lock free or exclusively or as
some type
of unique id
What would be really nice is a layer of abstraction above this all for
per-cpu data storage, eg something like:
per_cpu_storage_handle =
KeAllocatePerCpuStorage(sizeof(MY_STORAGE_TYPE));
and then in your dpc or isr:
current_cpu_data = KeGetCurrentCpuData(per_cpu_storage_handle);
not too hard to write your own of course, but harder to make it future
proof for changes like Windows 7.
My drivers maintain some per-cpu data and from reports I’ve had the
‘winlh’ build runs just fine under Windows 7, but I suspect that it
wouldn’t under a >64 CPU system, or even maybe NUMA. That said, my
drivers run in a VM under Xen and I suspect that if you are trying to
solve a problem by creating a VM with more than 64 CPU’s then you are
doing it wrong
James