Thread scheduling in 2.6 kernels

[Mulyadi Santosa]

Hi Mandeep

Quite long questions you have below...but I'll try to summarize and answer....

Btw, your problem description is great....I believe it helps (at least
/me) to get a sense what you gonna do, what you've done and how it
really works. A nice example for every one of us....

On Wed, Feb 23, 2011 at 21:16, Mandeep Sandhu
<mandeepsandhu.chd at gmail.com> wrote:

> We're working in an MIPS based embedded system, running a fairly old

OK, I take a bold note here. I only have in touch with x86 32 bit, so
what I am going to say might be completely wrong it is brought to MIPS
realm.

> Linux 2.6.22 kernel (with vendor provided BSP). We write UI

I remember vaguely that CFS (Complete Fair Scheduler) was improved
somewhere after 2.6.22 version...I couldn't recall exactly what
changes they are...

In fact, the latest "200 lines famous patch" also affect how scheduling works...

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

Why not shifting the network I/O to the decoder threat? or IMHO,
better...another separate thread? So each other could
overlap...between CPU computation and I/O.

> 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)

one is lowest, latter is highest? hmmmm if we put that back to pre CFS
era, that could mean a very different time slice assignment...or in
simpler word...kinda bad idea. I think if it's using nice value, it's
better if the difference is around 5 or 10 by maximum.

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

wait, so decoder just "eat" the content of the buffer without being
signaled before? in other word, it just work all the time?

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

OK...better....or signal...or any other kind of IPC that suits you....

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

I think this is the problem and that's why I proposed to isolate the
network I/O into separate thread. It's like ping pong, main thread
push new data, decoder thread wait...it is then woken
up..decoding...main thread waits....

Technically it is called priority inversion..if I got it correctly
about your situation.

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

Fixed? I don't think so. CFS is kinda using "delta" i.e if current
task runs for x and other which is waiting is y, then for the next
round, others deserve some kind of weighted x-y.

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

I think this trick might work: Check /proc/<pid>/maps or use pmap.
NPTL ones usually maps libtls in its process address space

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

so, no coreutils/util-linux/util-linux-ng?

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

everything under /proc/<pid>? have you checked that?

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com