Jaap-Jan Boor wrote:

Steve,

On 30-sep-04, at 19:39, Stephen Williams wrote:

quoted

I have a multi-threaded (pthreads) application running on an
embedded PPC. One of the threads operates a scanner video input,
and I want to give it (and only it) high priority, so that if
a device driver wakes it up, it is scheduled as close to "now"
as possible.

yes, if you run this program as root a priority >1 and class
SCHED_FIFO should work as expected.

The program is run by root and I'm using the pthread interface
to set the thread policy.

quoted

For the particular case I'm seeing, it seems to *not* have
any effect. My interrupt handler is activated (I see on the
scope) and in the first few cases the response is immediate,
but sometimes the response is delayed significantly.

Possible. What kernel version do you use? In my experience
a 2.4.x kernel with O(1) scheduler, preemptible kernel patch and low
latency patch still have significant delays (> 5 ms) sometimes.
A 2.4 kernel without these patches can have much longer response times.
I didn't experiment with the 2.6 kernel on this particular
system yet but 2.6 includes the O(1) scheduler and preemtible
kernel patch.

This is linuxppc-2.4 from bitkeeper. The last pull I did was a
few months ago, I think.

The process environment should be under control. There are a
half dozen idle daemons (init, boa, syslogd, mostly busybox)
and about a dozen threads in the application at hand. The
network and serial console should be idle during the test,
only my hardware should be going.

By the way, do you not share a lock with a lower priority thread?
If the lower priority thread has the lock, your high priority
thread needs to wait until it's finished (unlocks).

The program is working with in-house devices, I've written the
drivers. The device driver can be used in a pipeline-like fashion,
so the driver itself can be used for most synchronization. In
fact, The thread in question synchronizes entirely through the
driver. I guess that means its a candidate for a seperate process,
eh?

But that means, for this thread, all the synchronization is inside
the kernel. I can also see that there *should* be no cause to block
on anything at the instant I see the delay, hence my puzzlement.

Of course, I'm processing 24bit color images at 30MPixels/sec,
so I might well be hitting *PCI* scheduling issues as easily as
anything else.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."