las-RT_GROUP_SCHED

<ronj> hello, followup of my yesterday issue on jack failing to start under ubuntu natty: following adi advice on #ffado I ran jack in verbose mode, here is the crashlog: http://pastebin.com/xzvZxfkV . suggestions welcome
<las> ronj: yes, this is the standard issue that is coverted in the JACK FAQ
<las> ronj: did you read the link(s) i gave you?
<las> s/coverted/covered/
<ronj> las, yes. I'm running on my usual gear with my usual setup, my user is in the audio group, ulimit -l returns unlimited, ulimit -r returns 95, and my sampling rate matches my card sampling rate
<ronj> and I said yes to jack postinstall "do you want RT?"
<ronj> but I may be missing something
<ronj> also, I cleaned the mess done by the ubuntu studio controls app and I now have rt setup only in /etc/security/limits.d/audio.conf (nothing audio related in /etc/security/limits.conf)
<las> ronj: what version of ub is "natty" ?
<nedko> 11.04 ?
<las> nedko: 11?
<ronj> it is the current development version
<ronj> yes
<ronj> alpha1 at the moment
<las> ronj: then you are probably a victim of the new section
<ronj> yup
<las> ronj: see http://jackaudio.org/linux_group_sched
<las> ronj: you have no easy way out
<ronj> las, any idea on who on ubuntu side could take action on this? the kernel maintainer?
<ronj> (Alessio Bogani)
<ronj> or the jack/ffado maintainer?
<ronj> and what do you mean by "new section"?
<las> ronj: i wrote it up today
<las> ronj: this is ub kernel/userspace issue
<las> ronj: JACK can do nothing about it
<las> ronj: and it has nothing to do with FFADO
<las> ronj: i didn't state is quite so boldly, but for a typical user, having RT_GROUP_SCHED in ubuntu means that its basically unusable for RT work
<ronj> las, is this a compile-time kernel option? You advise disabling for the audio-targeted -lowlatency kernel?
<las> ronj: yes and yes
<las> ronj: but actually, for *any* kernel on which a normal user might ever want to run something with RT scheduling
<ronj> doing it right now then
<ronj> ok
<las> ronj: it *can* be done on your system, but it will be painful
<ronj> what do you mean?
<las> ronj: you have to (a) create a cgroup (b) assign resources to it (c) use a script that will join the cgroup and then exec its arguments so that they belong to the group
<ronj> las, one last thing: you mention it is the case since Ub 10.10, but I'm positive I ran jack on 10.10 with both -generic and -lowlatency. How is it possible?
<las> ronj: you can always run it without realtime scheduling but we STRONGLY advise against this
<las> ronj: its possible that the FFADO backend more or less requires an RT thread for its own internal purposes too
<las> ronj: a system that regular users cannot get RT scheduling is broken for JACK use, even though it is possible to get stuff done
<ronj> ok thanks for the clarification; mailing the ubuntustudio devel mailinglist
<las> ronj: hmm
<las> ronj: i'm reading more
<las> ronj: it seems that cgrules.conf could be used to at least put processes into the right group by default
<las> ronj: though this is still quite a baroque mechanism
<ronj> las, may I include you in the email I'm sending?
<las> ronj: sure, though jack-devel would be a much better idea
<ronj> ok adding jack-devel
<las> ronj: you're not danni coy, right?
<ronj> las, sorry?
<ronj> uh no
<las> ronj: new email on lau about the same issue
<ronj> heh ok
<ronj> also under ubuntu?
<las> ronj: natty
<ronj> reading
<ronj> las, which solution would you go for? 1. disabling RT_GROUP_SCHED for the -lowlatency kernel, 2. set up a cgroup and invoke JACK and every client from a shell script that joins the cgroup first, 3. use cgrules.conf
<las> ronj: i think that for the vast majority of users, (1) is the desirable option
<las> ronj: (2) would be next
<las> ronj: (3) would be hard, because it would enforce "application <foobar> always run in the <bazbar> cgroup" which is not really very useful or correct
<las> ronj: but more than that, (1) should be done for the non-lowlat kernel too
<las> ronj: there's no reason to require a lowlat kernel to use JACK
<las> ronj: many people get by without it just fine. with RT_GROUP_SCHED, its suddenly really quite tricky for them
<ronj> las, I don't understand why "<las> ronj: there's no reason to require a lowlat kernel to use JACK"
<las> ronj: http://jackaudio.org/realtime_vs_realtime_kernel
<ronj> las, ok. I think ubuntu's terminology for kernels is confusing you. -rt and -realtime are RT kernels (with ingo molnar patchset), while -lowlatency is a -generic kernel with some compile-time tweaks for audio
<ronj> in these terms, you say -rt is not needed and -lowlatency should be fine
<ronj> right?
<las> ronj: ah, sorry, i'm forgetting UB terminology
<las> ronj: my own feeling (today) is that for both kernels, RT_GROUP_SCHED is a mistake
<las> ronj: a mistake in that it makes using RT scheduling very difficult for users
<las> ronj: we've spent 10 years getting to a place where its almost kind of sort of easy
<las> ronj: this is a big step backwards
<ronj> :-/
<ronj> las, FYI I got surprisingly good results with -lowlatency: no xruns with -generic at 32ms, with -rt at 4ms, and with -lowlatency at 8ms
<ronj> las, why is this option there in the first place?
<ronj> would it make sense to disable it even in -generic?
<las> ronj: that would be my feeling yes
<las> ronj: this is a highly specialized kernel option
<las> ronj: its useful when building very customized embedded systems
<ronj> oooh ok
<las> ronj: its very hard to see its utility on a general purpose machine
<las> ronj: note something else too
<las> ronj: and this is kind of important
<las> ronj: the option itself is not the issue
<las> ronj: the default "root" cgroup is RT-enabled
<las> ronj: but something on the ub systems is putting user processes into a different cgroup that is not RT enabled
<ronj> las, if "the default "root" cgroup is RT-enabled", then why do I also have the problem when I run jack as root?
<las> ronj: so actually, option 1A (if they really want RT_GROUP_SCHED for some reason) is to ensure that whatever cgroup they are putting user tasks into is RT enabled by default
<las> ronj: the "root cgroup" has nothing to do with being root
<las> ronj: its "root" as in "root of a tree"
<ronj> ok