Sounds like you want make Threaded DPCs (which exist to fill the niche you talked about) the default model. Are you aware of Threaded DPCs? Why not just go down that route?
Your idea of targeting DPC-heavy drivers to lower their throughput is what MMCSS attempted (and still does) to do back in Vista -- it partly lead to a catastrophe as suddenly network card traffic on heavy audio I/O machines dropped to a mere fraction of full network bandwidth on a GigE network. What techniques have you developed to address these issues?
Other DPC throttling on I/O leads to priority inversion and inheritance problems, due to the heavy inter-dependency of Windows services and drivers. How do you plan on solving these challenges?
Most scalability bottlenecks in the 2003 scheduler are related to the dispatcher lock -- multiple highly threaded real time applications would encounter increased latency on many-core systems. How do you intend to solve this issue without removing the lock as well (which would cause multiple layer/version violations in ReactOS and take nearly as much time as removing it in Win7 took)?
How do you intend to balance real-time thread usage with multiple user/TS scenarios?
Also, I'm not sure what WaveRT/scheduler mode you are talking about. WaveRT was mostly changed to properly support Event-Mode in Win7, which is an issue entirely separate to scheduler changes.
Which "key" people have you spoken with? Have you spoken with Arun Kishan?
On 2009-12-21, at 11:40 PM, Jose Catena wrote:
I'm very glad you hear you saying that, Alex. Those are indeed requirements my implementation will have to comply with, and I think it is totally feasible. It should improve realtime class latency very meaningfully without making any other parameter worse, although I also expect to achieve improvements in other parameters too. What I intend to do is to fully comply with the real time paradigm, by using some very efficient solutions I have been using to eliminate the risks of rt priorities misuses without breaking the paradigm. For me that's the easy thing (and proven already), although some related ppl at MS had a very hard time to understand it. The real challenge is to handle DPCs as preemptable real time threads, fully respecting assigned rt priorities. This is what would fix the problem definitely, but since currently DPCs are not preemtable, there is a possibility of breaking some drivers because access serialization or sync issues. But I expect this possibility will be in real world very low, as there should not be interactions between DPCs created by different drivers out of system control, and ultimately, the new scheduler will be very flexible, allowing to configure each driver's DPCs parameters separately, so DPC preemption could be disabled for each particular driver or for all of them. Probably the default config will be fully compatible with current behavior, but I expect that enabling DPC preemption by lowering the priorities of selected driver's DPCs should work fine with the most or almost all drivers. I could post a more concise description of the plan, but what I intend ultimately to achieve is a fully working and tested ntoskrnl that could run on regular xp or s2003 too (to verify full compatibility). So maybe instead of writing the details and discussing it, we may wait till I have it working and speak again afterwards. This way I won't be wasting the time of anyone else until the objectives are achieved and can be verified.
P.D: Win7 has again improved the scheduler in the right direction (and fixed a related big mistake in the Vista's WaveRT model), but the DPC thing still kills the latency and they don't want to change that. I already discussed it with some key ppl at MS: a few understood it, but even those didn't think there were good chances of convincing decision makers anytime soon. It is considered a very low priority, if not null at all. But for all pro audio manufacturers, and some other niches like automation and control, it is a top priority.
Best regards,
Jose Catena DIGIWAVES S.L.
-----Original Message----- From: ros-dev-bounces@reactos.org [mailto:ros-dev-bounces@reactos.org] On Behalf Of Alex Ionescu Sent: Tuesday, 22 December, 2009 04:10 To: ReactOS Development List Subject: Re: [ros-dev] MSVC
If your new implementation:
- Is better than what Windows does today (hint: it's nearly lockless in Win
7, and O(1) since 2003) in every single way (ie: not sacrificing 50% of desktop users for 10% of server users).
AND
- Maintains full compatibility with Windows applications (and I expect you
to TEST this), drivers, etc in every way.
I promise you I will wholeheartedly support its inclusion in ReactOS.
In fact, I will do even more than just that.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
Best regards, Alex Ionescu