Timothy Normand Miller wrote:
On 4/19/07, James Richard Tyrer <[EMAIL PROTECTED]> wrote:

At first look, it appears to me that the service ISR could cause latency
problems with the sync interrupt if they share the same interrupt.  This
is the real issue that needs to be discussed.

You are right about that.  But I don't see how _we_ can fix it.  This
is the domain of OS experts, like the people on LKML.

The only thing that we can do is use two interrupts. Whether or not this helps will depend mostly on the hardware that it is plugged into, and the system software that is controlling it.

Besides, I have a tendency to want to design things so that latency is
not an issue.  For instance, we want to save on CPU overhead by
putting a GPU-using process to sleep after it's queued up a bunch of
requests.  We need to wake it up at some point to have it continue.
The solution is to design it so that the interrupt comes when the GPU
is still busy but nearing the end of being busy so that the producer
of commands can start producing them again before the last batch is
finished being processed.  This way, the GPU stays busy constantly,
regardless of the latency on interrupts or, far far worse, the time
required to wake the user process back up again.

Yes, that is the way to handle the service interrupt. Doesn't fix the sync interrupt issue though. The best fix for the sync interrupt is to figure out a way that it isn't needed, at least it doesn't need to be routed off of the board. If you could set up the I/O processor so that it would wait for the interrupt, this might be usefully. Or, if we are using double buffering, the sync interrupt could trigger the buffer switch.

Hanging 50 IRS off of one interrupt line is bad.  But I think we're
going to encounter other problems that make that pale in comparison.

I have an old system that only has the 15 AT interrupts and my disk controller (2 x IDE) only has one interrupt line. Two system interrupts conflict and I think that the Kernel's interrupt sharing system is dealing with that. But, I am having interrupt issues from time to time. The older 2.6.x Kernel was getting mad and disabling one of them. Upgrading the Kernel did fix that annoyance, but the disk controller still doesn't work too well.

With VLSI chips now common and cheep, there is no excuse for hardware not supporting 4 hardware interrupts for each PCI slot! Actually, just adding a second APIC to the southbridge chip should do it.

--
JRT

_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)

Reply via email to