On Wed, Dec 15, 2010 at 1:08 PM, Dhaval Giani
> On Wed, Dec 15, 2010 at 7:03 PM, Paul Davis
>> Its not just one JACK process. Its all JACK clients, the names of
>> which are not known in advance. JACK is a server client system that
>> may involve many different applications.
> Are they all forked by the main jack process? How many threads are
> privileged to RT priority?
1 per process.
>> What was written on the page at jackaudio.org was written out of
>> ignorance about how to set up cgroups. It was written as a page for
>> JACK end users, for whom the type of instructions you listed would be
>> reason enough to simply walk away.
> Even an instruction as simple as
> open /etc/sysconfig/cgconfig and change the line which says
> DEFAULT_CGROUP=yes to DEFAULT_CGROUP=no ?
that's adequate as a workaround to the while thing, yes.
> Right. So here is my question. What do you think can be done to
> improve the current state of the tools? Jan, Ivana and Balbir (on the
> cc) are also involved in the libcgroup project and we are very much
> committed to improving the state of tools. However either we are
> looking at the problem from a programmer's perspective or an
> administrator's perspective. So what do you, as an end user need?
> Would you be willing to help us out?
Well, RT_GROUP_SCHED doesn't offer anything to the pro-audio/music
creation community at all. It would be much easier for us if it just
wasn't there at all, and if it was there, if it had no side effects.
Turning of the default cgroup might be enough. But really, this is
something that neither JACK application developers nor JACK end users
have any reason to deal with.
Just parenthetically, JACK and many JACK applications also run on OS
X. Do you know what is needed to get access to realtime scheduling on
setThreadToPriority(thread, 96, TRUE, 10000000);
that's it. It works on every OS X system, for every user. We don't
expect Linux to follow this behaviour - POSIX makes that hard enough
already, and its role as a server and multi-user platform make that
impractical. But I hope you can perhaps understand how incredibly
irritating it is that *just* as almost mainstream distros now finally
come with the mechanism to grant ordinary users SCHED_FIFO and memlock
without too much hassle (its taken more than 8 years to get there),
RT_GROUP_SCHED appears without any apparent appreciation for the
impact on what is probably the most widely used RT-scheduled
application "ecosystem" on Linux.