Guest User

las-RT_GROUP_SCHED

a guest
Dec 13th, 2010
100
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. <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
  2. <las> ronj: yes, this is the standard issue that is coverted in the JACK FAQ
  3. <las> ronj: did you read the link(s) i gave you?
  4. <las> s/coverted/covered/
  5. <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
  6. <ronj> and I said yes to jack postinstall "do you want RT?"
  7. <ronj> but I may be missing something
  8. <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)
  9. <las> ronj: what version of ub is "natty" ?
  10. <nedko> 11.04 ?
  11. <las> nedko: 11?
  12. <ronj> it is the current development version
  13. <ronj> yes
  14. <ronj> alpha1 at the moment
  15. <las> ronj: then you are probably a victim of the new section
  16. <ronj> yup
  17. <las> ronj: see http://jackaudio.org/linux_group_sched
  18. <las> ronj: you have no easy way out
  19. <ronj> las, any idea on who on ubuntu side could take action on this? the kernel maintainer?
  20. <ronj> (Alessio Bogani)
  21. <ronj> or the jack/ffado maintainer?
  22. <ronj> and what do you mean by "new section"?
  23. <las> ronj: i wrote it up today
  24. <las> ronj: this is ub kernel/userspace issue
  25. <las> ronj: JACK can do nothing about it
  26. <las> ronj: and it has nothing to do with FFADO
  27. <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
  28. <ronj> las, is this a compile-time kernel option? You advise disabling for the audio-targeted -lowlatency kernel?
  29. <las> ronj: yes and yes
  30. <las> ronj: but actually, for *any* kernel on which a normal user might ever want to run something with RT scheduling
  31. <ronj> doing it right now then
  32. <ronj> ok
  33. <las> ronj: it *can* be done on your system, but it will be painful
  34. <ronj> what do you mean?
  35. <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
  36. <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?
  37. <las> ronj: you can always run it without realtime scheduling but we STRONGLY advise against this
  38. <las> ronj: its possible that the FFADO backend more or less requires an RT thread for its own internal purposes too
  39. <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
  40. <ronj> ok thanks for the clarification; mailing the ubuntustudio devel mailinglist
  41. <las> ronj: hmm
  42. <las> ronj: i'm reading more
  43. <las> ronj: it seems that cgrules.conf could be used to at least put processes into the right group by default
  44. <las> ronj: though this is still quite a baroque mechanism
  45. <ronj> las, may I include you in the email I'm sending?
  46. <las> ronj: sure, though jack-devel would be a much better idea
  47. <ronj> ok adding jack-devel
  48. <las> ronj: you're not danni coy, right?
  49. <ronj> las, sorry?
  50. <ronj> uh no
  51. <las> ronj: new email on lau about the same issue
  52. <ronj> heh ok
  53. <ronj> also under ubuntu?
  54. <las> ronj: natty
  55. <ronj> reading
  56. <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
  57. <las> ronj: i think that for the vast majority of users, (1) is the desirable option
  58. <las> ronj: (2) would be next
  59. <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
  60. <las> ronj: but more than that, (1) should be done for the non-lowlat kernel too
  61. <las> ronj: there's no reason to require a lowlat kernel to use JACK
  62. <las> ronj: many people get by without it just fine. with RT_GROUP_SCHED, its suddenly really quite tricky for them
  63. <ronj> las, I don't understand why "<las> ronj: there's no reason to require a lowlat kernel to use JACK"
  64. <las> ronj: http://jackaudio.org/realtime_vs_realtime_kernel
  65. <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
  66. <ronj> in these terms, you say -rt is not needed and -lowlatency should be fine
  67. <ronj> right?
  68. <las> ronj: ah, sorry, i'm forgetting UB terminology
  69. <las> ronj: my own feeling (today) is that for both kernels, RT_GROUP_SCHED is a mistake
  70. <las> ronj: a mistake in that it makes using RT scheduling very difficult for users
  71. <las> ronj: we've spent 10 years getting to a place where its almost kind of sort of easy
  72. <las> ronj: this is a big step backwards
  73. <ronj> :-/
  74. <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
  75. <ronj> las, why is this option there in the first place?
  76. <ronj> would it make sense to disable it even in -generic?
  77. <las> ronj: that would be my feeling yes
  78. <las> ronj: this is a highly specialized kernel option
  79. <las> ronj: its useful when building very customized embedded systems
  80. <ronj> oooh ok
  81. <las> ronj: its very hard to see its utility on a general purpose machine
  82. <las> ronj: note something else too
  83. <las> ronj: and this is kind of important
  84. <las> ronj: the option itself is not the issue
  85. <las> ronj: the default "root" cgroup is RT-enabled
  86. <las> ronj: but something on the ub systems is putting user processes into a different cgroup that is not RT enabled
  87. <ronj> las, if "the default "root" cgroup is RT-enabled", then why do I also have the problem when I run jack as root?
  88. <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
  89. <las> ronj: the "root cgroup" has nothing to do with being root
  90. <las> ronj: its "root" as in "root of a tree"
  91. <ronj> ok
RAW Paste Data