Thread scheduling in 2.6 kernels

[Mandeep Sandhu]

Hi Guys,

I'm posting on this list after a very long time...so plz excuse me if
my question is OT.

I had some doubts on how threads are scheduled in 2.6 kernels.

A little background of my "issue" first.

We're working in an MIPS based embedded system, running a fairly old
Linux 2.6.22 kernel (with vendor provided BSP). We write UI
applications on top of this system using QT. One of the applications
is a photo-viewer like app which fetches image data from the n/w and
displays them on the screen in a grid-like manner. The app shows
images in a "paged" manner so going from one page to another requires
animating the grid with a new set of images.

Now the task of decoding the incoming image data is very CPU intensive
and so is the animation part. So we used to see the animation suffer
when images (for next page were being decoded). So we though of
offloading the decoding part to a low priority thread. The main thread
mostly used to do 2 main operations - animation (CPU intensive) and
n/w i/o (blocking IO). The decoder thread was given the lowest
priority and the main GUI thread was given the highest priority (this
is QT thread priority and not pthread priority, but QT internally maps
such priorities to OS specific values)

This helped improve the animation, but 2 implementations that we tried
were giving very different and unexpected results:

1. In our first implementation the decoder thread was always running,
i.e it was busy-looping even when there was no data to work on. BUT,
we were observing that it was getting a chance to run _only_ when the
main thread was idle! So it almost looked like once the main thread
finished animating (a CPU intensive task) the other thread was getting
a chance to run and we used to see all the enqueued images decoded in
a "batch". In this implementation the animation was completely smooth
as no decoding operation was hampering it.

2. In our 2nd implementation,  since busy looping was not a good idea,
we changed the decoder thread to sleep (blocking on a mutex) when
there was no job to be done. Surprisingly, in this implementation the
animation was suffering again. We could see the decoder thread run
in-between the main thread's run (which was animating the UI) which
could possibly explain the poor animation performance.

So my questions:

- In the second implementation, why was the low-priority thread
running in-between and while doing a busy-loop caused it ran only when
the main thread was idle? One of my colleague suggested that since
busy-looping is CPU bound, the kernel might be giving it a "nice"
value penalty causing it priority to change dynamically.

- Is there still a concept of fixed process timeslices for scheduling
of processes?

- How can I find out if the kernel supports NPTL (kernel managed
threads) or plain old linux threads (user-space managed threads)?

I was trying to find out more info about the threads when the app is
running (using "ps" etc), but it seems that the most useful options
are not available in the busybox ver that I'm using.

Any other way to get more thread related info about a running application?

And again, sorry if this is OT.

Thanks,
-mandeep