X is still getting sustained priority in this one; This version addressed
other more important issues. The next version may help when I've made it.
>
> > 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.
Well if it gets real time scheduling all that goes away.. But of course that
would mean it needs root or equivalent user access. Even the lowest priority
real time apps get scheduled ahead of any nice priority boosted or
interactive boosted normal scheduling apps. However I'm going to give X less
buffer in the next version so it should get better without RT scheduling.
WRT the other lkml threads, audio should work without skips on normal desktop
loads without priority changes, without root privileges and without RT
scheduling. Therefore I am still considering it a regression.
>
> 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.
I assume you're not asking for the scheduler to be tweaked for this. You want
the 3d rendering to occur regardless of what is happening anywhere else? If
it doesn't use much cpu time but wakes lots then in it's current form the
scheduler will happily put this equal sharing with everything at nice 0. X
intermittently gets cpu hungry so will make this slow down at the moment
during those bursts. Your app will go ahead of everything else at a priority
of -3.
If it is cpu hungry, it will need at least -8 to get in on the act, and -13 to
be ahead of everyone (not really recommended though).
Con
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/