noidea_77 :
I never implied that a single core can not run my mouse and a do know about how time slicing works, but you may want to read a bit more why the scheduler has to be "multicore and architecture aware" here: http://www.intel.com/technology/itj/2007/v11i4/9-process/5-multi-core-scheduling.htm. That also explains why the scheduler needs an update to respond correctly to the accidentally different numbering of the FX cores. There is also this article about the fair scheduling implemented with Vista. The aim of it is basically that my program will NOT stop responding long before drivers have ran out of resources.
The scheduler improvements you talked about are real, and pretains to thread level parallism. But what I was saying is that threads are one type of a computational routine on a CPU, and as such, they are several levels (2, I think) below drivers (in terms of IRQ levels, which determine the priority of a given task), which are DPCs. Drivers may use helper threads for additional tasks. But fundamentally, the portion responsible for your crucial things like mouse, video and sound, etc all occur at a higher priority level than threads. They also get to take dibs on which core they want. The windows scheduler can THEN assign the unused processor time to juggling threads. This is why, when all else being typical on a modern win-OS, there is no possible way your drivers will run out of computational results before your programs. If your mouser driver is sending packets of data to be processed at say, 10khz (which is WAY below that of modern CPU clocks, and roughly on the order of USB polling intervals on most computers), then that 10khz of cycle is laid out to be used by the CPU first and foremost in a queue of DPCs, which is independent from the threads waiting to be executed. On the FX series, the scheduler still works the same way no matter which windows patch you run. It can only assign threads to different cores. Whether or not it does this efficiently is not the same as how DPCs are ran on computers, which as I said, occur at a different IRQ level all together.
Bottom of the line is, schedulers schedule threads, which pretains to multi-threading. Drivers and such occur at the DPC (deferred procedural calls) level. As such, the fundamental components of the drivers (not helper tasks/threads) are always given priority on the CPU, far before threads are. Threads are (if I remember correctly), level 0 IRQ wise, the least important of the IRQ levels. The recent improvements to threading are all made to this level, all the other fundamental levels (system clock, etc) are untouched by mere scheduler changes.
Straight from MS (http://msdn.microsoft.com/en-us/windows/hardware/gg487402.aspx):
An interrupt request level (IRQL) defines the hardware priority at which a processor operates at any given time. In the Windows Driver Model, a thread running at a low IRQL can be interrupted to run code at a higher IRQL.
The number of IRQLs and their specific values are processor-dependent. The IA64 and AMD64 architectures have 16 IRQLs and the x86-based processors have 32. (The difference is due primarily to the types of interrupt controllers that are used with each architecture.) Table 1 is a list of the IRQLs for x86, IA64, and AMD64 processors.
Table 1. Interrupt Request Levels
IRQL IRQL value Description
x86 IA64 AMD64
PASSIVE_LEVEL 0 0 0 User threads and most kernel-mode operations
APC_LEVEL 1 1 1 Asynchronous procedure calls and page faults
DISPATCH_LEVEL 2 2 2 Thread scheduler and deferred procedure calls (DPCs)
CMC_LEVEL N/A 3 N/A Correctable machine-check level (IA64 platforms only)
Device interrupt levels (DIRQL) 3-26 4-11 3-11 Device interrupts
PC_LEVEL N/A 12 N/A Performance counter (IA64 platforms only)
PROFILE_LEVEL 27 15 15 Profiling timer for releases earlier than Windows 2000
SYNCH_LEVEL 27 13 13 Synchronization of code and instruction streams across processors
CLOCK_LEVEL N/A 13 13 Clock timer
CLOCK2_LEVEL 28 N/A N/A Clock timer for x86 hardware
IPI_LEVEL 29 14 14 Interprocessor interrupt for enforcing cache consistency
POWER_LEVEL 30 15 14 Power failure
HIGH_LEVEL 31 15 15 Machine checks and catastrophic errors; profiling timer for Windows XP and later releases
Threads occur at PASSIVE_LEVEL, while driver processes occur at DISPATCH_LEVEL.