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(a)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:
1) 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
2) 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.