Re: [Discuss-gnuradio] SCHED_FIFO and NPTL

[Eric Blossom]

On Wed, Mar 01, 2006 at 09:25:13AM +0100, Stephane Fillod wrote:
> 
> > On 2/26/06, Eric Blossom <address@hidden> wrote:
> > > There is some fairly straight-forward work that can be done to reduce
> > > the latency of the user mode code, and that's probably a good first
> > > step.  This would also including enabling real-time scheduling for the
> > > signal processing threads (SCHED_FIFO), reducing the amount of user
> > > space buffering for the USRP (no need to mess with the generic
> > > buffering in GNU Radio, it's not the problem), and transfering smaller
> > > chunks of data across the user/kernel boundary (that that won't help
> > > throughput!).
> 
> This step would be very good!
> 
> If we go the SCHED_FIFO way, it would be neat to be able to enable it on 
> a thread by thread basis. Actually, the Omnithread library has already
> support for SCHED_FIFO policy for POSIX systems. Since running
> applications as root is no good, what we're missing here is a wrapping 
> of POSIX libcap in Omnithread/POSIX to gain secheduling priviledges, 
> pretty much the same way JACK is doing it, as explained here[2]. Then,
> thanks to the realtime-lsm kernel module, regular users of a group
> can gain access to the SCHED_FIFO policy. The audio guys went before
> us, the libcap and realtime-lsm package can be found on most moderns 
> distros.
> 
> The day we leave the SCHED_OTHER safe world, GNU Radio will need to have
> implemented in its flowgraph scheduler a watchdog to spare at least 1%
> when choking 100% of the CPU time...
> 
> [2] http://jackit.sourceforge.net/docs/faq.php#a5

Stephane, do you know the current status of this[2] situation:

  Currently (as of 2.6.7) JACK has a serious problem creating
  SCHED_FIFO threads for real-time processing. It is unclear whether
  this is a bug in JACK, in the new Native PThreads Library (NPTL), or
  in the 2.6 kernel. At the moment no one has a solution, but there is
  a workaround: define LD_ASSUME_KERNEL=2.4.19 in the environment of
  the jackd process and of every JACK client. The easiest way to do
  this is setting it in ~/.profile , or wherever you customarily
  define global environment variables. Glibc developer Ulrich Drepper
  explains the operation of LD_ASSUME_KERNEL in more detail.

Using LD_ASSUME_KERNEL=2.4.19 effectively forces the old (pre-NPTL)
behavior, which means that acquiring an uncontested mutex requires a
trip to the kernel.  I believe it also means that mutexes won't work
in shared memory across process boundaries.  Those seem like total
losers to me...

Eric