Note that I said “assuming all devices are equally important”, which is
often an invalid assumption; perhaps the correct statement would have been
“Assuming the all devices are equally important belies the fact that they
are, in real systems, *not* equally important; consequently, this assumption
leads to a problem analogous to the priority-inversion problem when a device
which actually *is* more important (in terms of meeting an interrupt latency
requirement) is blocked for an indeterminate time because it is erroneously
treated as a peer of all the other devices.”
I didn’t realize I needed to be so precise in stating what seemed obvious.
The PCI BIOS certainly does assign priorities; I know this because in some
bizarre cases I’ve had to go into the PCI BIOS setup to reserve an
non-exclusive interrupt line, and my choice of reserved line impacted the
priority; it took some experimentation to discover which line gave the best
performance (although this was far enough in the past that I was probably
working with a PIC system). Embedded systems, including MS-DOS systems, do
not have any code to assign device priorities, yet the device priorities are
nonetheless assigned. I never had to assign device priorities when working
on embedded x86 systems, yet they were clearly assigned. One of the
problems we had was that for devices that required low-latency service, the
priorities were assigned incorrectly relative to what we needed. But
sometimes we just couldn’t get the priorities assigned in the way we wanted.
Note that in a single app, the designer of the app gets to assign the thread
priorities based on an understanding of the relative importance of the
threads. This is also what we did in real-time operating systems; and
techniques such as rate monotonic analysis take these priorities and thread
execution times can be used to determine the balance of the thread mix and
the priorities can be adjusted to achieve a feasible solution.
A device driver, on the other hand, works in isolation; it cannot determine
its importance relative to a set of unknown device drivers in any given
situation. Therefore, it is not as simple as in working with a mix of
threads in a single app. Note also that the “thread priority” game only
works well in vertical market systems where the entire collection of apps is
predetermined; the impact of manipulating thread priorities in a system with
an unknown set of applications running is also unsolvable. I’m not sure how
any application writer can magically determine the correct thread priorities
to set to achieve a specified performance without (a) interfering with
unknown and unknowable apps that may coexist or (b) being interfered with by
unknown and unknowable apps.
In one case, we gave up 25% of the CPU resources to guarantee both the GUI
remained responsive and the realtime-constrained threads handled their
workload correctly; the trick is to SetThreadAffinityMask for the GUI to one
CPU (arbitrarily, CPU0) and the worker threads to the system mask & ~1 (that
is, to never run on CPU0). But note that this required some serious
assumptions that are not necessarily consistent with a general-purpose
system, but we were working in a vertical-market application turnkey-system
style environment.
When I deliver an app, and I have discovered the (very rare) need to
manipulate thread priorities, I always make these choices settable so an end
user can adjust them to make sure they work in the real environment in which
the app must live. Ultimately, the priorities can only have meaning in
context. A given app may work well with one priority assignment and fail in
another, and each such instance would be determinable only in the context of
the system which is actually running with its existing mix of applications.
In the case of device drivers, the importance of an interrupt may also
profoundly affect my application’s responsiveness, which is what I’ve
encountered in practice. But I didn’t know how to solve the problem.
joe
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@hotmail.com
Sent: Friday, July 31, 2009 6:52 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Interrupt Routing – was: Question abuot masking
interrupt
Assuming that all devices are equally important can lead to the priority
inversion problem.
If you think about it carefully you will realize that the above statement
contradicts itself - priority inversion just
does not make sense when everyone is equally important, don’t you think…
What I don’t understand is how a PCI BIOS can *a priori* determine how
important a device
is relative to other devices.
BIOS does not assign priorities to devices …
Also note that using a priority-ordered DPC queue simply changes the
problem slightly; the issue
of how priorities are established remains a problem.
I think this decision can be left to driver writers pretty much the same way
decisions about thread priorities are left to app ones. The argument that
everyone would want to have the highest possible priority
seems to be faulty - if your device’s minimal latency comes at the price of
unresponsive GUI you will, apparently, think twice about trying it…
Anton Bassov
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
–
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.