JACK and RT cgroups

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

Re: JACK and RT cgroups

Chris Caudle
On Thu, December 16, 2010 5:05 pm, alex stone wrote:
> Still, we have what you've decided we should have, so
>i guess we'll need to make the best of it, or not, as the
> ordinary user decides.

Isn't this ire pointed in the wrong direction?  I haven't been following
all the traffic on the kernel development groups, but it looks to me like
Dhaval Giani is the developer of libcgroup, which is just as neutral as
any other capability provided on a Linux kernel, and what you really need
to be complaining about is how the distributions choose to use that
capability.  Dhaval has explained how it is trivially easy to not use
cgroup capabilities, as well as to add RT scheduling to a cgroup, so if a
particular distribution is setting up cgroups in such a way that RT use is
broken, complain to that distribution.

This thread started out with a complaint that a particular release of
Ubuntu was broken. Does Dhaval work for Canonical?  Is Dhaval in any way
responsible for how Ubuntu sets up the default cgroups?  If not, then
complain to Canonical, not Dhaval.  It looks to me like Dhaval has been
going out of his way to help explain how to work around someone else's
misuse of a feature, and what he gets in return is a bunch of bitching and
moaning.  That doesn't really seem like the productive way to get help.

--
Chris Caudle


_______________________________________________
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: JACK and RT cgroups

Paul Davis
On Thu, Dec 16, 2010 at 6:12 PM, Chris Caudle <[hidden email]> wrote:

> complain to Canonical, not Dhaval.  It looks to me like Dhaval has been
> going out of his way to help explain how to work around someone else's
> misuse of a feature, and what he gets in return is a bunch of bitching and
> moaning.  That doesn't really seem like the productive way to get help.

this is all true. but it also lacks context. it lacks the context of
the developers and deployers of both the kernel and various
distributions, how can i put it, screwing over users (and developers)
that need RT for years and years and years. Dhaval is not responsible
for any of that, and in fact, he's almost certainly not responsible
for the state of affairs in current Ubuntu. but when an issue like
this comes up in this community, its not a new thing for us - its just
another example of being told by people who apparently have the power
to make decisions that they haven't bothered to ask us and in fact
don't really consider our use case all that important. Again, this is
not Dhaval's doing, but is it endemic to the way that RT is treated by
many parts of the linux infrastructure world. this isn't the first
time, and its probably not the last. even when i was the linux
plumbers conference last year, very few of the people doing work on RT
capabilities even knew about JACK (there are a couple of notable
exceptions who have made it their business to be aware of how JACK
works, what it does, etc.)

what's particularly galling about this particular case is that
although it would be hard to prove, the JACK community is probably the
biggest and most intense user base for RT functionality in the Linux
world (there may be some mobile stuff that i'm not aware of that
relies on it too, and then that would be bigger, for sure). and yet
nobody who has been developing access mechanisms, policies or
utilities for RT scheduling has (to my knowledge) ever come to ask us
"would this help? would this make it worse? does this make sense?" i
have no idea of Dhaval's role in aspect of things - it may be pretty
minimal - but unfortunately Dhaval has ended up taking a bit of hit
for poking his head up (thanks!) and saying "hey, I'm involved with
this stuff", not because anyone is angry with him specifically, but
because we're all just a bit tired of being treated this way and
people jumped on the first guy brave enough to look like he might
care.

so, yeah, Dhaval, sorry for some of the more negative energy you've
had sent you way from around here. its not that people are not
genuinely angry about all this, but we're certainly not personally
angry with you.

--p
_______________________________________________
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: JACK and RT cgroups

Dhaval Giani
[Going offlist, because I have no interest in continuing this
discussion publicly, but I did want to point out something]

On Fri, Dec 17, 2010 at 1:37 AM, Paul Davis <[hidden email]> wrote:

> On Thu, Dec 16, 2010 at 6:12 PM, Chris Caudle <[hidden email]> wrote:
>
>> complain to Canonical, not Dhaval.  It looks to me like Dhaval has been
>> going out of his way to help explain how to work around someone else's
>> misuse of a feature, and what he gets in return is a bunch of bitching and
>> moaning.  That doesn't really seem like the productive way to get help.
>
> this is all true. but it also lacks context. it lacks the context of
> the developers and deployers of both the kernel and various
> distributions, how can i put it, screwing over users (and developers)
> that need RT for years and years and years. Dhaval is not responsible
> for any of that, and in fact, he's almost certainly not responsible
> for the state of affairs in current Ubuntu. but when an issue like
> this comes up in this community, its not a new thing for us - its just
> another example of being told by people who apparently have the power
> to make decisions that they haven't bothered to ask us and in fact
> don't really consider our use case all that important. Again, this is
> not Dhaval's doing, but is it endemic to the way that RT is treated by
> many parts of the linux infrastructure world. this isn't the first
> time, and its probably not the last. even when i was the linux
> plumbers conference last year, very few of the people doing work on RT
> capabilities even knew about JACK (there are a couple of notable
> exceptions who have made it their business to be aware of how JACK
> works, what it does, etc.)
>

Not really. So here are a few questions that I will ask you, and that
would help give a lot of context
a. Who are the linux-rt developers?
b. Who is paying them?
c. How are these employers exploiting RT

You will start seeing the pattern of development that happens.

> what's particularly galling about this particular case is that
> although it would be hard to prove, the JACK community is probably the
> biggest and most intense user base for RT functionality in the Linux
> world (there may be some mobile stuff that i'm not aware of that
> relies on it too, and then that would be bigger, for sure).

Now that is just presumptive, and not the fact. If JACK were such big
community of linux-rt then more people would be concerned about them.
I know only about JACK because my professor uses them for all this
testing work, because JACK is a nice test case. I have been involved
in Linux development for sometime, and there are too many other use
cases that I am aware of. Eg. Embedded systems, "enterprise" realtime
(I am not going into more details for obvious reasons). So if it is so
important, why doesn't one of these companies which make it their
business to know JACK hire one kernel developer full time to ensure
that the RT needs to JACK are taken care of? Sorry, I call bullshit
here.

> and yet
> nobody who has been developing access mechanisms, policies or
> utilities for RT scheduling has (to my knowledge) ever come to ask us
> "would this help? would this make it worse? does this make sense?" i
> have no idea of Dhaval's role in aspect of things - it may be pretty
> minimal - but unfortunately Dhaval has ended up taking a bit of hit
> for poking his head up (thanks!) and saying "hey, I'm involved with
> this stuff", not because anyone is angry with him specifically, but
> because we're all just a bit tired of being treated this way and
> people jumped on the first guy brave enough to look like he might
> care.
>

So this is a feedback loop. You get upset, and rant out at someone who
might be interested in helping you. That someone is not paid to take
care of your requirements, so (s)he loses interest and stops bothering
about you. Someone new comes in, and the cycle repeats. At the end of
the day, JACK says that "linux kernel folks are screwing us over", and
linux kernel folks say, "JACK is not a community interested in
anything outside their narrow usecase". Both of which are misleading.
So, let's just lose this negative energy.

> so, yeah, Dhaval, sorry for some of the more negative energy you've
> had sent you way from around here. its not that people are not
> genuinely angry about all this, but we're certainly not personally
> angry with you.

Now, at the end of the day, here is my position. I have my exams
coming up in little over a month. I am not paid to work on JACK. My
professor likes using it, so there are issues. I know how to use
libcgroup and setup cgroups the right way, and be done with it. The
JACK community is just interested in ranting and raving as opposed to
helping me out (apart from one notable exception) or listening to me.
I ask myself, why do I even bother with JACK? I have been discussing
with torbenh on IRC on what the current shortcomings are, and how to
fix them, and also looking at fixing those issues myself (with code in
libcgroup + JACK). But even after a patch coming out, with all the
negativeness, I ask myself yet again. Why should I bother with JACK?
Does this reaction justify me looking at it?

Dhaval
_______________________________________________
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: JACK and RT cgroups

Dhaval Giani
On Fri, Dec 17, 2010 at 12:26 PM, Dhaval Giani <[hidden email]> wrote:
> [Going offlist, because I have no interest in continuing this
> discussion publicly, but I did want to point out something]
>

hmm. i seem to have fat fingered somewhere and this went out to the list :-).

/me sits red-faced for sometime.
_______________________________________________
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: JACK and RT cgroups

torbenh
In reply to this post by Dhaval Giani
On Thu, Dec 16, 2010 at 08:01:46PM +0100, Dhaval Giani wrote:

> On Thu, Dec 16, 2010 at 7:53 PM, Dominique Michel
> <[hidden email]> wrote:
> > Le Wed, 15 Dec 2010 20:07:37 +0100,
> > Dhaval Giani <[hidden email]> a écrit :
> >
> >> > Turn about again, and i suggest that the jack/RT implications as
> >> > part of "being fair to all, with no favourites' weren't given any
> >> > consideration, or you wouldn't be here now.
> >> >
> >>
> >> Someone made a noise, and so I knew about it. Not about jack being a
> >> favourite. If projectX would have an issue, and I would be informed, I
> >> would be equally willing to help them. I however would not be in a
> >> position to keep a look at all projects out there and what issues they
> >> would face if featureY came into existence.
> >>
> >> > I'm not throwing a tantrum, just staggered that something like this
> >> > could happen in the first place. It just seems so obvious, as a
> >> > logical process of feature construction, to consider wider
> >> > implications, as you wrote, for all users, including chaps that use,
> >> > and/or code for, jack/RT.
> >> >
> >>
> >> Considering the fact that its only JACK facing issues (or at least
> >> complaining), that too after two years of a feature being in existence
> >> and after about a year for the default cgroup being created, I think
> >> the decision was just fine.
> >
> > I am a non coding project administrator. My distro of choice is gentoo,
> > so I am able to configure, compile and install a kernel.
> >
> > As such, I think than the less you can make is to add a text into the
> > kernel help that address the fact that RT_GROUP_SCHED and CGROUPS will
> > break any rt enabled software without expropriated setup, and that
> > with a pointer to the documentation that will show how to do such a
> > setup.
> >
>
> I am still not seeing where RT_GROUP_SCHED and CGROUPS breaks any rt
> enabled software. As has been repeated on this thread countless number
> of times, there is *no* issue in the kernel. The issue is that by
> default the userspace tools create a default group (I still hold to
> the view that it is the right thing to do.). An application which uses
> rt privileges is *special*. Either,
> a) The application should make it much easier for the user to use this
> capability (by for example creating the appropriate cgroups and so
> on), so that it works out of the box or,
> b) Inform the user what he needs to do very clearly and have the user
> do the hard work.
>
> What is being repeated again and again that making a one line change
> to a configuration file is going to discourage new users. As I have
> mentioned again and again, this has been in there for a few months
> now, and if it were such a big deal, there would have been tons of bug
> reports. Also, this problem is going to come up again once systemd
> comes into play. So it has to be fixed by the application as opposed
> to people coming about and complaining how Linux developers are
> totally against the jack community and are out to get them by making
> such changes.

well... this seems to be your first contact to the world of real users
who are not admins ;P
they perceive missing permissions as broken !!!!

there are also grotesque myths still showing up in irc.
like "you need an RT PREEMPT kernel for SCHED_FIFO"
this is what we deal with.

>
> So, as has been done in the past in this thread, there are folks who
> have stepped up to the challenge, and there are patches already
> floating about. Instead of encouraging them, and supporting them (with
> reviews and the like), instead folks are coming, repeating this
> conspiracy theory.

the users cant review my patches. (some of them cant even apply them :S)

>
> The only way to move forward is for rt applications to be aware that
> Linux is different, and if you want your application to work out of
> the box, some changes need to be made.
>
> This is my last post on non-technical issues in this thread.

lets just move the technical discussion to the followups of the patch.
we still dont have good documentation for users what needs to be done.

i only have a vm with debian squeeze with cgroups enabled and libcgroup.

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

--
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: JACK and RT cgroups

Gabriel M. Beddingfield-2
In reply to this post by Dhaval Giani
On Fri, Dec 17, 2010 at 5:26 AM, Dhaval Giani <[hidden email]> wrote:
> [Going offlist, because I have no interest in continuing this
> discussion publicly, but I did want to point out something]

FWIW, I don't think there's anything in this e-mail to be red-faced
about.  In fact, I was thinking, "Now we're getting somewhere!" :-)

> (I am not going into more details for obvious reasons). So if it is so
> important, why doesn't one of these companies which make it their
> business to know JACK hire one kernel developer full time to ensure
> that the RT needs to JACK are taken care of? Sorry, I call bullshit
> here.

BOSS: How's the new sequencer engine coming?
PROPELLERHEAD: Um, I had to pull off to figure out CGROUPS.  I'm
working with the developers to get it configured right.
BOSS: What's CGROUPS?
PROPELLERHEAD: It's a new way to manage scheduling in the kernel.
After I enable it, the audio apps stop working because they can't get
RT scheduling.
BOSS: But it worked before, right?
PROPELLERHEAD: Yes.
BOSS: Can you disable it?  Do we need it?
PROPELLERHEAD: Yes, I can disable it.  No, I can't see why we need it.
BOSS: Well, disable it!  Geez!  What do I pay you for??

-gabriel
_______________________________________________
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: JACK and RT cgroups

torbenh
In reply to this post by Fernando Lopez-Lezcano
On Thu, Dec 16, 2010 at 02:00:38PM -0800, Fernando Lopez-Lezcano wrote:

> On 12/16/2010 03:17 AM, Dhaval Giani wrote:
> >On Thu, Dec 16, 2010 at 12:00 PM,<[hidden email]>  wrote:
> >>I agree that cgroups can be very useful for some type of systems
> >>(which are probably quite different from a typical single-user
> >>audio workstation). If any error was made, it was not by the people
> >>developing cgroups, but by a distro mainly targeting  'personal'
> >>computer users enabling it. I very much hope the upstream default
> >>will be to disable this, so it won't affect all other distros.
> >
> >No, the problem is not with that, but with a default setup which works
> >for most users. I know it does not work for you, and there is no
> >disagreement in that. However, that policy does work for most users
> >and turning it off is just a matter of adding a line in a config file,
> >I am not so inclined to change it.
>
> As a packager (Planet CCRMA, rpm based) I would very much prefer
> that adding a _file_ somewhere (not replacing a file, or editing a
> file) would have the intended effect (ie: disabling the whole
> system, or appropriately configuring cgroups to allow for rt
> shceduling).
>
> If that were the case it would be trivial to create a package that
> does the right thing. The user installs it and voila, he/she/it has
> now access to rt scheduling as before (and does not need any
> knowledge of the internals).
>
> _Changing_ a file, on the other hand, is not so easily done through
> packaging. Actually, it is a pain.

working with the libcgroup people to provide this facility.
i already baked a very simple patch for libcgroup.

going to create the necessary stuff in jackd soon.

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

--
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: JACK and RT cgroups

Fernando Lopez-Lezcano
On 12/17/2010 08:06 AM, torbenh wrote:

> On Thu, Dec 16, 2010 at 02:00:38PM -0800, Fernando Lopez-Lezcano wrote:
>> On 12/16/2010 03:17 AM, Dhaval Giani wrote:
>>> On Thu, Dec 16, 2010 at 12:00 PM,<[hidden email]>   wrote:
>>>> I agree that cgroups can be very useful for some type of systems
>>>> (which are probably quite different from a typical single-user
>>>> audio workstation). If any error was made, it was not by the people
>>>> developing cgroups, but by a distro mainly targeting  'personal'
>>>> computer users enabling it. I very much hope the upstream default
>>>> will be to disable this, so it won't affect all other distros.
>>>
>>> No, the problem is not with that, but with a default setup which works
>>> for most users. I know it does not work for you, and there is no
>>> disagreement in that. However, that policy does work for most users
>>> and turning it off is just a matter of adding a line in a config file,
>>> I am not so inclined to change it.
>>
>> As a packager (Planet CCRMA, rpm based) I would very much prefer
>> that adding a _file_ somewhere (not replacing a file, or editing a
>> file) would have the intended effect (ie: disabling the whole
>> system, or appropriately configuring cgroups to allow for rt
>> shceduling).
>>
>> If that were the case it would be trivial to create a package that
>> does the right thing. The user installs it and voila, he/she/it has
>> now access to rt scheduling as before (and does not need any
>> knowledge of the internals).
>>
>> _Changing_ a file, on the other hand, is not so easily done through
>> packaging. Actually, it is a pain.
>
> working with the libcgroup people to provide this facility.
> i already baked a very simple patch for libcgroup.

That would be great... so far Fedora is not affected but it is probably
just a matter of time, and it would be nice to be ready when it happens :-)

> going to create the necessary stuff in jackd soon.

Thanks!

-- Fernando
_______________________________________________
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: JACK and RT cgroups

Lennart Poettering-16
In reply to this post by Dhaval Giani
On Wed, 15.12.10 19:32, Dhaval Giani ([hidden email]) wrote:

>
> On Wed, Dec 15, 2010 at 7:27 PM, Peter Nelson <[hidden email]> wrote:
> > On Wed, 2010-12-15 at 18:33 +0100, Dhaval Giani wrote:
> >
> >> Now, I am not inclined
> >> to change that because JACK is a special case and in most cases normal
> >> users should not be launching rt processes and in case there is
> >> someone else, they can explicitly provide those powers.
> >
> > Actually this affects RealtimeKit and PulseAudio as well.
> >
>
> I haven't seen pulseaudio having issues. (Or at least no complaints
> from Lennart)

Well, that's because PA is pretty defensive and if we run into drop-outs
we back off. PA doesn't need RT sched, it's just happy if it gets it.

Also, on the distro I care for (Fedora) we don't sort normal processes
into any subgroup of "/" by default, which Ubuntu however does.

If you ask me then the libcgroup default config should not sort any
process into any cgroup by default and leave everything in "/".

Before we start sorting user processes into their own cgroups we need to
carefully make sure that this can be done without ill effects on the
individual cgroups. Turns out using the "cpu" hierarchy by default
*does* have ill effects, and hence I am tempted to change systemd to no
longer sort into cgroups in the "cpu" hierarchy anymore.

Quite frankly I believe that the "cpu" controller is kinda broken and
should be split into two: one that handles non-rt processes, and one
which handles rt processes. The fact that when i want to limit the
impact of normally scheduled processes I also have to limit their RT
behaviour is seriously limiting. And since the RT shares are limited
globally I see no sensible workaround for good defaults that wouldn't
break stuff like JACK.

Lennart

--
Lennart Poettering - Red Hat, Inc.
_______________________________________________
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: JACK and RT cgroups

torbenh
On Fri, Dec 24, 2010 at 09:32:45AM +0100, Lennart Poettering wrote:

> On Wed, 15.12.10 19:32, Dhaval Giani ([hidden email]) wrote:
>
> >
> > On Wed, Dec 15, 2010 at 7:27 PM, Peter Nelson <[hidden email]> wrote:
> > > On Wed, 2010-12-15 at 18:33 +0100, Dhaval Giani wrote:
> > >
> > >> Now, I am not inclined
> > >> to change that because JACK is a special case and in most cases normal
> > >> users should not be launching rt processes and in case there is
> > >> someone else, they can explicitly provide those powers.
> > >
> > > Actually this affects RealtimeKit and PulseAudio as well.
> > >
> >
> > I haven't seen pulseaudio having issues. (Or at least no complaints
> > from Lennart)
>
> Well, that's because PA is pretty defensive and if we run into drop-outs
> we back off. PA doesn't need RT sched, it's just happy if it gets it.
>
> Also, on the distro I care for (Fedora) we don't sort normal processes
> into any subgroup of "/" by default, which Ubuntu however does.
>
> If you ask me then the libcgroup default config should not sort any
> process into any cgroup by default and leave everything in "/".
>
> Before we start sorting user processes into their own cgroups we need to
> carefully make sure that this can be done without ill effects on the
> individual cgroups. Turns out using the "cpu" hierarchy by default
> *does* have ill effects, and hence I am tempted to change systemd to no
> longer sort into cgroups in the "cpu" hierarchy anymore.
>
> Quite frankly I believe that the "cpu" controller is kinda broken and
> should be split into two: one that handles non-rt processes, and one
> which handles rt processes. The fact that when i want to limit the
> impact of normally scheduled processes I also have to limit their RT
> behaviour is seriously limiting. And since the RT shares are limited
> globally I see no sensible workaround for good defaults that wouldn't
> break stuff like JACK.

+1

this was pretty much the question i asked in #lxcontainers after which
this discussion has been started.
i am basically moving individual threads into different cgroups now.
this looks like a bandaid, because i doubt this was actually intended.


>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

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