enabling packagers to provide a sane default RT enabled cgroup

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

enabling packagers to provide a sane default RT enabled cgroup

torbenh

hi...

assuming we have the config dir working, and packagers can create
cgroups by dumping a file into /etc/cgconfig.conf.d/

how should this work.

letme make the goal clear:
in current debian squeeze when i install the jackd package, i am asked
whether i want to enable RT scheduling for the audio group. if i answer
with yes, a file is dumped into /etc/security/limits.d

---------------------------------------------------------------------
#Provided by the jackd package.
#
# Changes to this file will be preserved.
#
# If you want to enable/disable realtime permissions, run
#
#    dpkg-reconfigure -p high jackd

@audio   -  rtprio     95
@audio   -  memlock    unlimited
#@audio   -  nice      -19

---------------------------------------------------------------------

before the cgroups, this was sufficient to allow jack apps to access
sched_fifo. now i would like to enable a similar solution for libcgroup.

the problem however is that we can only create a single rtaudio cgroup
because we can not overcommit the bandwidth in several groups.

it seems like we need to advise packagers to create a package containing
the RT cgroup and make all apps needing RT depend on it.

seems a bit dumb to do this. but it probably boils down to this.
anybody got better ideas ?


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

Fons Adriaensen-2
On Mon, Dec 20, 2010 at 02:51:53PM +0100, torbenh wrote:

> the problem however is that we can only create a single rtaudio cgroup
> because we can not overcommit the bandwidth in several groups.
>
> it seems like we need to advise packagers to create a package containing
> the RT cgroup and make all apps needing RT depend on it.
>
> seems a bit dumb to do this. but it probably boils down to this.
> anybody got better ideas ?

Wouldn't it be possible to just put RT trheads in the 'root' cgroup
which has RT enabled ?

In the long term I see another danger. Since cgroups + systemd
allow distros to control RT capabilities in a safe and detailed
way, they might be tempted to give RT shares to e.g. desktop
packages in order to have a 'competitive edge' in responsiveness.
In a sense cgroups and systemd would make RT *too easy* to use
and abuse. If such things start happening, and since RT can't be
overcommited, there may be little left for any audio work if it
depends on a specifically created cgroup. We would not just need
a package that provide RT to audio packages, but one the cleans
up the other packages' mess as well.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

Paul Davis
On Mon, Dec 20, 2010 at 10:07 AM,  <[hidden email]> wrote:
>We would not just need
> a package that provide RT to audio packages, but one the cleans
> up the other packages' mess as well.

I think that is why torben is suggesting the creation of an RT-enabled
cgroup be considered a distinct "package" or "function" and one not
tied to any particular other package (but potentially depended upon by
others). This way there would (hopefully) be only 1 RT-enabled
(non-root) cgroup on any system that had this stuff.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

torbenh
In reply to this post by Fons Adriaensen-2
On Mon, Dec 20, 2010 at 04:07:25PM +0100, [hidden email] wrote:

> On Mon, Dec 20, 2010 at 02:51:53PM +0100, torbenh wrote:
>
> > the problem however is that we can only create a single rtaudio cgroup
> > because we can not overcommit the bandwidth in several groups.
> >
> > it seems like we need to advise packagers to create a package containing
> > the RT cgroup and make all apps needing RT depend on it.
> >
> > seems a bit dumb to do this. but it probably boils down to this.
> > anybody got better ideas ?
>
> Wouldn't it be possible to just put RT trheads in the 'root' cgroup
> which has RT enabled ?

i think cgrulesengd can move stuff there.
however, only root can move things into the root group.
so this will fail with jacks cgroup moving code.

>
> In the long term I see another danger. Since cgroups + systemd
> allow distros to control RT capabilities in a safe and detailed
> way, they might be tempted to give RT shares to e.g. desktop
> packages in order to have a 'competitive edge' in responsiveness.
> In a sense cgroups and systemd would make RT *too easy* to use
> and abuse. If such things start happening, and since RT can't be
> overcommited, there may be little left for any audio work if it
> depends on a specifically created cgroup. We would not just need
> a package that provide RT to audio packages, but one the cleans
> up the other packages' mess as well.

it did not happen with limits.conf, i doubt that it will happen here.
really, we audio guys are extremely liberal with wanting to grant RT
privs to our users. but most other communities are extremely cautious
with that.
back in the days i never saw the cd burning people crying for
sched_fifo, for example.


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

Paul Davis
On Mon, Dec 20, 2010 at 10:47 AM, torbenh <[hidden email]> wrote:

> back in the days i never saw the cd burning people crying for
> sched_fifo, for example.

actually, they did. the original author of cdrecord used to insist
that you should run it as root because it needed SCHED_FIFO. he was
ignored, mostly.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

torbenh
On Mon, Dec 20, 2010 at 10:49:34AM -0500, Paul Davis wrote:
> On Mon, Dec 20, 2010 at 10:47 AM, torbenh <[hidden email]> wrote:
>
> > back in the days i never saw the cd burning people crying for
> > sched_fifo, for example.
>
> actually, they did. the original author of cdrecord used to insist
> that you should run it as root because it needed SCHED_FIFO. he was
> ignored, mostly.

yeah. i always ran it as root :S


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

Fons Adriaensen-2
In reply to this post by torbenh
On Mon, Dec 20, 2010 at 04:47:40PM +0100, torbenh wrote:

> i think cgrulesengd can move stuff there.
> however, only root can move things into the root group.
> so this will fail with jacks cgroup moving code.

Are you sure ?

I just tried this:

fons@zita1:~> su
root@zita1:/> cd /
root@zita1:/> mkdir cgroup
root@zita1:/> mount -t cgroup -o cpu,memory default_group cgroup
root@zita1:/> cd cgroup
root@zita1:/cgroup> la
total 4
drwxr-xr-x  2 root root    0 Dec 20 18:59 .
drwxr-xr-x 25 root root 4096 Dec 20 18:59 ..
--w--w--w-  1 root root    0 Dec 20 18:59 cgroup.event_control
-r--r--r--  1 root root    0 Dec 20 18:59 cgroup.procs
-rw-r--r--  1 root root    0 Dec 20 18:59 cpu.rt_period_us
-rw-r--r--  1 root root    0 Dec 20 18:59 cpu.rt_runtime_us
-rw-r--r--  1 root root    0 Dec 20 18:59 cpu.shares
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.failcnt
--w-------  1 root root    0 Dec 20 18:59 memory.force_empty
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.limit_in_bytes
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.max_usage_in_bytes
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.memsw.failcnt
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.memsw.limit_in_bytes
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.memsw.max_usage_in_bytes
-r--r--r--  1 root root    0 Dec 20 18:59 memory.memsw.usage_in_bytes
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.move_charge_at_immigrate
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.oom_control
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.soft_limit_in_bytes
-r--r--r--  1 root root    0 Dec 20 18:59 memory.stat
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.swappiness
-r--r--r--  1 root root    0 Dec 20 18:59 memory.usage_in_bytes
-rw-r--r--  1 root root    0 Dec 20 18:59 memory.use_hierarchy
-rw-r--r--  1 root root    0 Dec 20 18:59 notify_on_release
-rw-r--r--  1 root root    0 Dec 20 18:59 release_agent
-rw-r--r--  1 root root    0 Dec 20 18:59 tasks

Started qjackctl, jackd, some apps as normal user. No complaints.
All of them show up in /cgroup/tasks.

Total DSP load was around 20%. Then (as root)

  echo 100000 > /cgroup/cpu.rt_runtime_us

produced xruns and interrupted sound, and

  echo 950000 > /cgroup/cpu.rt_runtime_us

restored things to normal.

So it seems nothing at all is required to move processes into
the default group. Apparently it's where things end up unless
and until they are moved manually or by the daemon.

Ciao,


--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: enabling packagers to provide a sane default RT enabled cgroup

Dhaval Giani
>
> So it seems nothing at all is required to move processes into
> the default group. Apparently it's where things end up unless
> and until they are moved manually or by the daemon.
>

As a past thread has discussed, there is a default cgroup created
where are all non-rt processes are moved, and it has no rt runtime. A
process cannot move back to the root cgroup after that unless root
does it. If you think it doesn't matter, it does because systemd will
create cpu cgroups by default, and you will hit this again.

Dhaval
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org