It’s not that bad. Guess where is the bottleneck ? when you want to have
several media stream !. I was put on the spot, and my tail is on fire, but
we do have temporarily non-sharable interesting result(s). We do have some
characterization about who comes first, second etc as bottleneck under
farily
represtative workload and setup, OS is not that bad yet, others are jamming
for
desparate help.
For the publicly available ( a part of the story) could be found on the
recent
computer journal of IEEE.
-prokash
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of Moreira, Alberto
Sent: Tuesday, February 17, 2004 6:29 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
The best interrupt is no interrupt. Things like AV playback should be
handled 100% on the south side of the bus, no need to involve the processor
in it. I believe that if you run into performance issues because of
interrupt latency, it’s about time to migrate to a better architecture !
Alberto.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com]On Behalf Of
xxxxx@3Dlabs.com
Sent: Tuesday, February 17, 2004 9:21 AM
To: Windows System Software Devs Interest List
Subject: RE: Re:[ntdev] Re:Interrupt Latency of ACPI vs Standard PC
Loren,
Ideally the system should be completely self-tuning and the
user’s options
limited to a single “Go Faster” slider, or more likely push
button, and the
system will read the user’s mind and figure out what he
*really* wants,
since he probably can’t actually express it himself in most
cases. In a
less ideal world, one has to deal with more factors, and not
all of them can
be static if truely optimal performance is the goal.
I think the computer will be very confused if it could read my
mind ;-).
>
> Which gets me to idly wondering about the concept of truely dynamic
> interrupt routing/tuning as part of an adjustable performance
> strategy.
> Processes and threads have adjustable priorities so that the user (or
> someone) can give an indication of relative desires. I start
> wondering if
> it would be reasonable to have interrupt affinity and priority levels
> adjustable dynamically, much like thread priority. If you consider a
> device/driver to be a process, then adjusting its relative
> priority doesn’t
> sound like that strange a concept.
There are many conflicting goals to satisfy here, and the scheduling of
which interrupt gets the highest priority is never going to be
straightforward.
Obviously, a system where you have some sort of real time needs, say AV
playback, will need to have fast enough response-time on the relevant
interrupts to the AV playback. But if you raise the importance of the sound
card, and thus reduce the importance of the hard disk interrupt, you may get
problems to get the data across to the sound card. So although the latency
to the real-time critical part is lower, you’ve missed the goal-post by a
side effect of trying to get to the goal.
[The above is a completely made up example, and just for illustration
purposes. Please change devices around as you please. There is always some
sort of dependancy between one interrupt and another, that may cause things
to go wrong.]
In the ideal world, it shouldn’t really matter which interrupt has what
priority, because all interrupts are handled within such a short time that
the next one doesn’t get affected by the latency of other priorities.
This will of course not happen, but I believe the MS initiative to keep
interrupts short is a good one. This will certainly help. Now there’s of
course one problem with this: A system that has LOTS of interrupts, the
scheduling of DPC or some other mechanism to send work off to a lower IRQL
will take a lot of extra time. Not good for overall performance. So someone
will break the rules to improve performance, and we’re back at the beginning
of a “not so ideal world”.
I’m sometimes amazed at what slowness is allowed for interrupts to be
handled in Windows, and the system still runs nicely (i.e. it doesn’t crash
or behave too badly, you may get glitches in sound or video, but that’s it).
It’s very interesting to see how long an interrupt can actually be held
pending. It seems that it is ALMOST FOREVER (in computer time)…
I think the idea of automatically/runtime adjusted interrupts is a fine
idea. It’s just the implementation of the prioritization routine that I have
a hard time figuring how it should work. I would tend to prioritize
interrupts that run short times, and let the longer ones run at lower
priority. That should reduce the average latency. Of course, it’s not good
for the server system where someone copies a 256KB packet of data from the
disk to the main memory inside the interrupt handler, but they shouldn’t be
doing that in the first place, eh? 
–
Mats
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@garlic.com
To unsubscribe send a blank email to xxxxx@lists.osr.com