Embedded Linux, pthreads and scheduling

[Stephen Williams]

Jaap-Jan Boor wrote:
> Steve,
> 
> On 30-sep-04, at 19:39, Stephen Williams wrote:
>> 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.

>>
>> 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."