Re: 2.5.74-mm1

Daniel Phillips
2003-07-05T17:31:36Z

On Saturday 05 July 2003 18:01, Con Kolivas wrote:
> Have you taken the next twist in the road? I posted a second patch which
> should go on top of what's in 2.5.74-mm1 a couple of days ago. Just in
> case, here is a link to it.
>
> http://kernel.kolivas.org/2.5/
>
> it's called patch-O2int-0307041440

This one is a regression. Window dragging now causes the same kind of
dropouts as I saw on 2.5.73 mainline. But see below.

> It makes significant headway in smoothing the corner cases. I need testing
> at each point before I can post another update, and am doing much less
> frequent smaller updates now, with the aim of having no more than one patch
> for each -mm, so I can have a decent sized audience for each change.
>
> Andrew can you please apply this one on top in the next -mm if you are to
> continue testing this patch series.

Well...

It should help you to know that up till now I've been running Zinf at priority
0 (of -20..19). I just changed change that to -10, and all the dropouts went
away. Duh. The thing is, Zinf is a (soft) realtime application, or at least
the sound servicing part of it is. It's hard to see how the kernel can ever
figure that out automagically - it has to be told. So I told it.

My only reservation is that nice is not a very (ahem) nice way of doing this.
We really want Zinf to take care of that itself. Zinf knows it has a
realtime component and it knows which component that is, so it needs to tell
the kernel, presumeably via setpriority (nice is just a frontend to
setpriority). Blindly choosing some higher priority to run at is certainly
crude, but for now it solves the problem, so I won't have to apologize to my
wife about destroying her audio experience with the latest, greatest kernel.

Not having to worry about detecting and babying along the realtime sound
thread should make your job considerably easier. OK, looking at the Zinf
code I see that it does know about thread priority, via pthreads. It's
either not working, or it's not set to sensible defaults. I'm looking into
that.

Now, just so this doesn't get too easy for you, I have a nice little opengl
application here:

http://nl.linux.org/~phillips/world.tgz
(3D engine - see screenshots on the same page)

The "bounce" demo is suitable for testing how steady the framerate is. It's
working pretty well since 2.4.73, if you leave the window in one place, but
scheduling gets challenging (i.e., sucks) when you drag the 3D window around.
How should we fix that? It's my code so I'm willing to add whatever priority
control is appropriate.

Regards,

Daniel