fc2, xorg, 2.6.x, scheduling latency peaks

[Fernando Pablo Lopez-Lezcano]

[to the Jack Devel list readers: this is the tail end of a thread in
which I was trying to get help to debug xruns under FC2/2.6.6/xorg -
turns out that pthread_create was not doing the same thing as before :-]

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

Just confirmed this with a first preliminary hack (and test). Jack
creates new threads and to do that it sets up a pthread_attr_t struct
and uses pthread_attr_setschedpolicy and pthread_attr_setscope to set
the scheduling policy (and also sets the priority) in the struct. Then
pthread_create is called (with that struct as an argument) and the
thread is created. But the thread created is _not_ SCHED_FIFO and there
is no error return. If _after_ the thread is created I double check the
scheduling policy and use pthread_setschedparam to again set it to
SCHED_FIFO then the thread changes to SCHED_FIFO... go figure...

The previous behavior was different (< FC2). If pthread_create could not
create the thread with the right scheduling then an error would be
returned (and another hack would be activated in the code to take into
account another failure of glibc to do things properly :-)

Anyway, so the kernel is not at fault and graphics are not at fault. 

Suggestions on how to proceed? I have a hack I just tested for a minute
and with that the xruns are apparently gone. It would be better to try
to trace this to the real source of the problem. 

Thanks very much for the help, specially to Arjan for steering me in the
right direction. As usual what kills you are the assumptions :-(

-- Fernando