fc2, xorg, 2.6.x, scheduling latency peaks

Fernando Pablo Lopez-Lezcano nando at ccrma.Stanford.EDU
Wed Jun 2 19:11:27 UTC 2004


On Wed, 2004-06-02 at 11:34, Arjan van de Ven wrote:
> On Wed, Jun 02, 2004 at 11:28:20AM -0700, Fernando Pablo Lopez-Lezcano wrote:
> > > > > A real test with the Jack low latency server reveals that something else
> > > > > is creating latency hits.
> > > > 
> > > > do you run Jack as realtime process ??
> > > 
> > > Correct, it is running SCHED_FIFO. I'm using Jack O'Quin LSM realcap
> > > module to grant non-root users those privileges (compiled as a module in
> > > the kernel). 
> > > 
> > > Just occured to me, is there anything else in FC2 that may be running
> > > SCHED_FIFO?? I'll try to find out. 
> > 
> > Using schedutils (chrt) I find no tasks or threads running SCHED_FIFO.
> > And the realtime threads of jack are apparently running SCHED_FIFO.
> > Argh, that would have been too easy :-)
> 
> can you try to NOT run it realtime? 

Sure, just tried that. Lots _more_ xruns, move around the mouse, xruns,
switch windows, xruns :-)

> Sounds odd but when you use realtime
> behavior you have to be really careful for priority inversion situations (eg
> if X doesn't run at such a high prio, but your RT task needs to wait on X to
> draw something..)

Aha! I think you are on to something! I double checked the priority of
the jack clients and _they_ are not getting SCHED_FIFO!! They should be
getting that priority from the jack server but they are not (and the
jack server is not complaining at all so no error is being raised).
Probably some change in glibc, I would think... (remember, this is all
working perfectly in < FC2). 

That's probably the cause of the xruns. 
Now I have to find out why...
(I also have to test 2.6.x under FC1 with the trick you mentioned
earlier in the thread). 

Thanks!
-- Fernando






More information about the fedora-devel-list mailing list