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

Paul Davis
On Wed, Dec 15, 2010 at 1:31 PM, Dhaval Giani <[hidden email]> wrote:
> Honestly. I was completely unaware that the jack folks were facing
> this issue until I saw the cgroups page. What upset me was that this
> page was put up, but no attempt made to contact the developers who are
> doing this work. (Not to mention inaccurate information). So I ask
> this question, are jack users this special case for which the
> developers should look out for, or like other users they let us know
> when they are facing issues?

Although some of us have been involved in kernel development in the
past, and some of us keep our eye from time to time on things going on
in kernel land or at the kernel/userspace boundary, for the most part
we don't tend to track these developments until they start negatively
impacting our user base.

In this case, systems with cgroups have been around for a while, and
some of us have played a little with using them. It turns out that
some people were even working on systems with RT_GROUP_SCHED enabled,
without any issues. It was only when we began to get reports from
users of the latest Ubuntu systems about how the mechanism that used
to enable RT access was broken that we started looking into it.

Now, you may not know our history with this sort of thing, but
basically, over the years, we've become quite used to the kernel
screwing us over, and of it being extremely difficult to get anyone to
pay attention because they will just go on about our needs are "too
specialized". That's why its been so gratifying that finally many
distros are getting the "out of the box" configuration correct (or
close enough).

finally, this is NOT a new bug or situation. I direct your attention
to, for example:

  https://bugzilla.kernel.org/show_bug.cgi?id=10361

which is from 2008, and was basically ignored.

i apologize for not getting in touch with you, but that was because we
had no idea who "you" was. it was unclear the extent to which this
was/is a ubuntu problem, a userspace problem, a kernel problem or some
combination of all of the above.
_______________________________________________
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

Alex Stone
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 9:31 PM, Dhaval Giani <[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 7:19 PM, alex stone <[hidden email]> wrote:
>> Dhaval,
>> So as jack users (non-coders), with many of us having invested
>> hundreds and possibly thousands of hours testing for our modest
>> community, not to mention the most definitely thousands of hours of
>> sweat and toil put in by the all too few jack/RT coders who have
>> valiantly laboured most generously for like minded users in a shared
>> desire to have great, professional quality, audio/midi/video tools as
>> viable alternatives to proprietary locked in apps, we are being
>> reduced to a single label, entitled "Linux User" to satisfy a generic
>> perception of what someone, somewhere thinks is the definition of what
>> we "should" be using? Regardless of the limitations this imposes,
>> which is something we accuse proprietary OS's of?
>>
>
> Not really. As I mentioned, it is quite trivial to turn off all these
> features. I honestly cannot believe that adding an extra line in a
> configuration file will turn off users. If it is such a major issue,
> asking your distro to add that line by default should not be a
> problem. They should do so. Hey, if there are enough complaints,
> letting us know upstream will enable us to turn off the policy. I am
> aware of at least one distro which turns off the default group by
> default. But unless people let us know, we really cannot do something.
>
>> I respectfully wonder if the team that made this decision are aware of
>> the number of jack/RT users that actually pass through our little
>> village, or if the decisions being made are in earnest pursuit of a
>> wider generic user base, are reflective of an honest misunderstanding
>> of just how important jack/RT apps and infrastructure are for linux
>> users who would rather enjoy the superb stability of linux as a viable
>> professional system, over the angst that goes with the "others".
>>
>
> Honestly. I was completely unaware that the jack folks were facing
> this issue until I saw the cgroups page. What upset me was that this
> page was put up, but no attempt made to contact the developers who are
> doing this work. (Not to mention inaccurate information). So I ask
> this question, are jack users this special case for which the
> developers should look out for, or like other users they let us know
> when they are facing issues?
>
>> I'm bewildered by the indifference to what i thought was a sizable and
>> significant chunk of the linux community. It seems i misjudged the
>> importance and superb performance of a jack based system, over the
>> rest.
>>
>
> see above. I don't see jack as a special case. It would be very much
> appreciated if you let us knew you were facing issues. Its not that we
> want to make life tough for our users. But we need to know that we are
> making life tough for them :-). This works for most users, yes. If it
> were not, I am pretty sure we would have had tons of bug reports.
>
>> Now it seems we have to start again, yes? Based on what seems ever
>> increasing perception that all non coding linux users
>> are......."generic".
>>
>> Dhaval, i have no wish to offend you, but it looks as if you've posted
>> to us as some sort of apologetic afterthought. I appreciate you're in
>> a bit of a spot with this, but i hope you appreciate this will make
>> things more challenging for us, and make it even harder to encourage
>> new users into our village in the linux user community, when we will
>> have to walk fellow users though additional instructions to try and
>> get what we already had, and what was already challenging enough to
>> setup, for new initiates into the linux "way".
>>
>> Are we really of so little significance in the wider linux world?
>>
>
> Not really. Just a bit more noise would be great :-).
>
> Thanks
> Dhaval
>

Dhaval,
So no-one thought, while building this exciting new feature, to do a
quick test, or at least have a think about, of the significance of the
impact on jack/RT, given the nature of the feature as a scheduler, and
what many users think is JACK and jack based apps importance in the
linux community?

Sort of confirms the indifference to jack/RT as a significant
component in the linux audio/midi/video world, doesn't it?

I guess there's no going backward from here, but it's a little
presumptious to assume non-coding users are going to hang around
kernel central, in the hope that we'll understand what you're about to
do, and fire a message back to those who do understand it, given
they're already working like trojans, (The human variety), for our
benefit.

If we don't yell, we don't get considered?

I appreciate you took the time to respond, so i won't add anything else.

Regards,

Alex.
_______________________________________________
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
In reply to this post by Tommaso Cucinotta-2
On Wed, Dec 15, 2010 at 1:43 PM, Tommaso Cucinotta
<[hidden email]> wrote:
> Il 15/12/2010 19:39, Paul Davis ha scritto:

>> FFT's are very expensive. FX that rely on spectral data need them but
>> it will take a while to compute them. So the JACK client that does
>> this sort of thing will declare that it delays the signal somewhat,
>> and will shunt the FFT computation off into 1 or more supplementary
>> threads to avoid stopping the smooth flow of audio.
>
> The piece of the puzzle I'm missing is, in case the other thread(s) don't
> deliver the requested filtering operation on time, how can you avoid an
> audible glitch ?

when you generate audio output at time T, you're using spectral data
based on incoming audio at time T-P. the delay (P) is why this
processing adds latency to the graph. the reason you need more threads
is mostly to smooth out the computational load. the FFT thread(s) will
be quiescent some of the time, and very busy at others. you don't want
that in the RT audio thread.

> From another perspective: is such a feature perhaps much more useful on
> Jack-1 without the "jack2" multiprocessing/pipelining capability ?

not related. jack2 parallelizes JACK clients, not the internals of JACK clients.
_______________________________________________
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
In reply to this post by Paul Davis
On Wed, Dec 15, 2010 at 7:44 PM, Paul Davis <[hidden email]> wrote:

> On Wed, Dec 15, 2010 at 1:31 PM, Dhaval Giani <[hidden email]> wrote:
>> Honestly. I was completely unaware that the jack folks were facing
>> this issue until I saw the cgroups page. What upset me was that this
>> page was put up, but no attempt made to contact the developers who are
>> doing this work. (Not to mention inaccurate information). So I ask
>> this question, are jack users this special case for which the
>> developers should look out for, or like other users they let us know
>> when they are facing issues?
>
> Although some of us have been involved in kernel development in the
> past, and some of us keep our eye from time to time on things going on
> in kernel land or at the kernel/userspace boundary, for the most part
> we don't tend to track these developments until they start negatively
> impacting our user base.
>
> In this case, systems with cgroups have been around for a while, and
> some of us have played a little with using them. It turns out that
> some people were even working on systems with RT_GROUP_SCHED enabled,
> without any issues. It was only when we began to get reports from
> users of the latest Ubuntu systems about how the mechanism that used
> to enable RT access was broken that we started looking into it.
>

Right. So as a first step, could we confirm that the workarounds I
mentioned work. As a first step, while we figure out how to make it
easier to use these features, we can easily turn off the default
configuration to be "NO" upstream. I know of at least one libcgroup
developer who would whole heartedly support that decision.

> Now, you may not know our history with this sort of thing, but
> basically, over the years, we've become quite used to the kernel
> screwing us over, and of it being extremely difficult to get anyone to
> pay attention because they will just go on about our needs are "too
> specialized". That's why its been so gratifying that finally many
> distros are getting the "out of the box" configuration correct (or
> close enough).
>
> finally, this is NOT a new bug or situation. I direct your attention
> to, for example:
>
>  https://bugzilla.kernel.org/show_bug.cgi?id=10361
>
> which is from 2008, and was basically ignored.
>

You might not agree with it, Peter is right. It is not a bug. It is
expected behaviour. You might not like it, but it is expected :-).
(Also that bug-reporter used USER_SCHED, which was just a bad idea imo
:-) ). Now the issue is with a default group which does not have
rt-time to it. So either you give it rt-time, or you do not create a
default group. They are functionally equivalent as far as rt-processes
are concerned.

Thanks
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

Fons Adriaensen-2
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 07:11:46PM +0100, Dhaval Giani wrote:

> Well, that is also possible. I looked at a pid based grouping option
> under the (wrong as it turns out) impression that the jack parent
> thread would own all rt threads. But as I said, you can quite easily
> create a cgroup and change its gid permissions to a group, and instead
> of the <jack_user>:<process_name> cpu <jack group> line, add a
>
> @<jack_group> cpu <jack_cgroup>
>
> line which would do the exact same thing.

1) What would be meaning of e.g.

   cpu.rt_runtime_us = 500000;

in that case ? Is this a sum limit for all tasks started
by a user in jack_group, or per task ? In the latter case,
is each task assumed to take up the specified amount, and
admitted or rejected on that basis ? The latter won't work
at all - some jack clients may take 50% of a cpu, others
less than 1%, and in many cases the amount actually used
is variable and unknown a priori. So anything that decides
using 'worst case' logic will fail to do the right thing.

2) If a cpu is specified as in your example, does that
mean that RT threads must be bound explicitly to that
cpu in order to be accepted ?


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

Dhaval Giani
In reply to this post by Alex Stone
>
> Dhaval,
> So no-one thought, while building this exciting new feature, to do a
> quick test, or at least have a think about, of the significance of the
> impact on jack/RT, given the nature of the feature as a scheduler, and
> what many users think is JACK and jack based apps importance in the
> linux community?
>

You could turn around the question as, "ok, there is this new cool
feature being developed. It is useful, but is it useful for me?" I
have seen other developers come out with really cool ideas to use
these features. I am aware that the pulseaudio folks have looked to
try to exploit RT-cgroup (it did not do what they wanted, but that is
a different issue).

> Sort of confirms the indifference to jack/RT as a significant
> component in the linux audio/midi/video world, doesn't it?
>

It just confirms that we treat all our users the same, and don't give
special consideration to any one group. (unless of course those are
folks who work with the project and we know we are affecting them)

> I guess there's no going backward from here, but it's a little
> presumptious to assume non-coding users are going to hang around
> kernel central, in the hope that we'll understand what you're about to
> do, and fire a message back to those who do understand it, given
> they're already working like trojans, (The human variety), for our
> benefit.
>
> If we don't yell, we don't get considered?
>

AFAIK, either you let people who can do something about it know, or
you don't. In one case they might either do something and you are
happy, or they do nothing and you are justified in complaining about
it (to some extent). In the latter, you would just be throwing a
tantrum.

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

Paul Davis
In reply to this post by Fons Adriaensen-2
On Wed, Dec 15, 2010 at 1:52 PM,  <[hidden email]> wrote:

> 1) What would be meaning of e.g.
>
>   cpu.rt_runtime_us = 500000;
>
> in that case ? Is this a sum limit for all tasks started
> by a user in jack_group, or per task ? In the latter case,
> is each task assumed to take up the specified amount, and
> admitted or rejected on that basis ? The latter won't work
> at all - some jack clients may take 50% of a cpu, others
> less than 1%, and in many cases the amount actually used
> is variable and unknown a priori. So anything that decides
> using 'worst case' logic will fail to do the right thing.

fons - right now, there is no deadline scheduling in the mainstream
kernel, so i don't think that any decision making fo the kind you're
imagining is taking place. the rt_runtime_us is really a limit on the
total amount of RT-scheduled time for all tasks in cgroup, not a data
point for a heuristic. if the total for the cgroup exceeds the limit,
then nothing in the group will be rescheduled till the next "period"
(kernel scheduling period, not jACK related, obviously)

> 2) If a cpu is specified as in your example, does that
> mean that RT threads must be bound explicitly to that
> cpu in order to be accepted ?

no. its the other way around.

however, this doesn't replace cpu affinity, because the parent (root)
cgroup still has access to all processors, so anything in that cgroup
could still use the processors apparently assigned to a child group.
this is one of the details of cgroups that i find a bit wierd until i
thnk about it, then it makes sense, then its wierd again :)
_______________________________________________
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

Tommaso Cucinotta-2
In reply to this post by Dhaval Giani
Il 15/12/2010 19:31, Dhaval Giani ha scritto:
> Honestly. I was completely unaware that the jack folks were facing
> this issue until I saw the cgroups page. What upset me was that this
> page was put up, but no attempt made to contact the developers who are
> doing this work. (Not to mention inaccurate information). So I ask
> this question, are jack users this special case for which the
> developers should look out for, or like other users they let us know
> when they are facing issues?
As from my understanding, Jack users didn't connect this with
the default cgroup thing, but this possibility came up only now.
(actually, I didn't see yet any user acknowledging that disabling
the default group solves the experienced problem).
I assumed that connection just because, being a regular "user"
of the RT priority for research work, and having libcgroup
installed, I noticed this issue on recent distros immediately.
Actually, my experience was bad: before realizing what was
the real reason, I tried to search for a bug in our patched kernel
and the like, but in the end the most stupid thing that used to
work since I don't know what year to date:

   chrt -r 1 /path/to/whatever

seemed stopped to work. That's why I perfectly share the Jack
developers' view.

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
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
In reply to this post by Fons Adriaensen-2
>> line which would do the exact same thing.
>
> 1) What would be meaning of e.g.
>
>   cpu.rt_runtime_us = 500000;
>

Ah, ok.

So let me give a basic background on what rt-cgroups are (just so that
we have a clearer discussion here). So, cgroups basically is a
mechanism to group processes (arbitrarily). This is represented as a
ram based filesystem. Creating a group is as simple as doing a mkdir,
and when you list the files, you get their values. The values that we
put in the cgconfig.conf set the values in these files.

Now, for the rtcgroup, you have two control files, namely,
cpu.rt_runtime_us and cpu.rt_period_us . This means that the cgroup
will get cpu.rt_period_us microseconds every cpu.rt_period_us
microseconds. Since the default period is 1second, I set the runtime
to 500ms, so that means every second, that group can get a maximum of
50% CPU.

> in that case ? Is this a sum limit for all tasks started
> by a user in jack_group, or per task ?

It is the sum limit for all tasks.

> In the latter case,
> is each task assumed to take up the specified amount, and
> admitted or rejected on that basis ? The latter won't work
> at all - some jack clients may take 50% of a cpu, others
> less than 1%, and in many cases the amount actually used
> is variable and unknown a priori. So anything that decides
> using 'worst case' logic will fail to do the right thing.
>

There is no admission control for tasks. The logic comes in while
assigning bandiwdth to a cgroup.

> 2) If a cpu is specified as in your example, does that
> mean that RT threads must be bound explicitly to that
> cpu in order to be accepted ?
>

A cpu is not specified anywhere. CPUs are specified only if you are
using cpusets (but that raises a different problem altogether :-) )

Thanks,
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

Alex Stone
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 9:55 PM, Dhaval Giani <[hidden email]> wrote:

>>
>> Dhaval,
>> So no-one thought, while building this exciting new feature, to do a
>> quick test, or at least have a think about, of the significance of the
>> impact on jack/RT, given the nature of the feature as a scheduler, and
>> what many users think is JACK and jack based apps importance in the
>> linux community?
>>
>
> You could turn around the question as, "ok, there is this new cool
> feature being developed. It is useful, but is it useful for me?" I
> have seen other developers come out with really cool ideas to use
> these features. I am aware that the pulseaudio folks have looked to
> try to exploit RT-cgroup (it did not do what they wanted, but that is
> a different issue).
>
>> Sort of confirms the indifference to jack/RT as a significant
>> component in the linux audio/midi/video world, doesn't it?
>>
>
> It just confirms that we treat all our users the same, and don't give
> special consideration to any one group. (unless of course those are
> folks who work with the project and we know we are affecting them)
>
>> I guess there's no going backward from here, but it's a little
>> presumptious to assume non-coding users are going to hang around
>> kernel central, in the hope that we'll understand what you're about to
>> do, and fire a message back to those who do understand it, given
>> they're already working like trojans, (The human variety), for our
>> benefit.
>>
>> If we don't yell, we don't get considered?
>>
>
> AFAIK, either you let people who can do something about it know, or
> you don't. In one case they might either do something and you are
> happy, or they do nothing and you are justified in complaining about
> it (to some extent). In the latter, you would just be throwing a
> tantrum.
>
> Dhaval
>

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.

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.

Regards,

Alex.
_______________________________________________
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

Fons Adriaensen-2
In reply to this post by Paul Davis
On Wed, Dec 15, 2010 at 01:31:13PM -0500, Paul Davis wrote:

> On Wed, Dec 15, 2010 at 1:20 PM, Tommaso Cucinotta
> <[hidden email]> wrote:
>
> > Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
> > created by libjack to RT (for which it is easy to identify the Linux TID for
> > attaching it to the group), but it also allows the application clients to
> > pass
> > a *pthread_t* value through the API, in order to raise its priority to
> > RT. So, I guess now there's no way to recover the Linux TID from the
> > pthread_t, so such a feature wouldn't work anymore.
>
> this is correct, thanks for reminding me/us about that part of the JACK API.
>
> it used, for example, by clients that need to do RT processing such as
> FFT generation, but cannot afford to do it in the thread provided by
> JACK.

And not all code requiring this does use the Jack API to promote
threads to RT. Jconvolver (library) doesn't as it could very
well be used without Jack. Most of my other apps run also on ALSA,
so they also create their RT threads without using any Jack support
(and it's actually trivial once you have a C++ thread class).

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

Dhaval Giani
In reply to this post by Alex Stone
> 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.

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

Tommaso Cucinotta-2
In reply to this post by Fons Adriaensen-2
Il 15/12/2010 20:05, [hidden email] ha scritto:

> On Wed, Dec 15, 2010 at 01:31:13PM -0500, Paul Davis wrote:
>> On Wed, Dec 15, 2010 at 1:20 PM, Tommaso Cucinotta
>> <[hidden email]>  wrote:
>>
>>> Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
>>> created by libjack to RT (for which it is easy to identify the Linux TID for
>>> attaching it to the group), but it also allows the application clients to
>>> pass
>>> a *pthread_t* value through the API, in order to raise its priority to
>>> RT. So, I guess now there's no way to recover the Linux TID from the
>>> pthread_t, so such a feature wouldn't work anymore.
>> this is correct, thanks for reminding me/us about that part of the JACK API.
>>
>> it used, for example, by clients that need to do RT processing such as
>> FFT generation, but cannot afford to do it in the thread provided by
>> JACK.
> And not all code requiring this does use the Jack API to promote
> threads to RT. Jconvolver (library) doesn't as it could very
> well be used without Jack. Most of my other apps run also on ALSA,
> so they also create their RT threads without using any Jack support
> (and it's actually trivial once you have a C++ thread class).

Ok. Now, an issue comes immediately to my mind: what RT priority do you
run these additional threads at, and how does it relate to the
configured Jack priority, and to the fact that Jack may be actually
configured with or without RT support, etc. You  need to keep in sync
things, here, otherwise it doesn't work as you'd expect.

Thanks,

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
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

Alex Stone
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 10:07 PM, Dhaval Giani <[hidden email]> wrote:

>> 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.
>
> Dhaval
>

But it's not just ProjectX is it. Jack/RT is an important part of a
structural framework that puts linux ahead of the the rest in terms of
performance, reliability and stability for a sizable chunk of users.

We now have what we have, i guess. No turning back, or reviewing the
decision that led to this in the first place. I'm still mystified why
we need cgroups at all, and how many apps, hardware requirements, or
structural functions, either now, or in the future, it's intended to
accommodate.

Regards,

Alex.
_______________________________________________
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

Hermann Meyer
In reply to this post by Tommaso Cucinotta-2
Am Mittwoch, den 15.12.2010, 20:18 +0100 schrieb Tommaso Cucinotta:

> Il 15/12/2010 20:05, [hidden email] ha scritto:
> > On Wed, Dec 15, 2010 at 01:31:13PM -0500, Paul Davis wrote:
> >> On Wed, Dec 15, 2010 at 1:20 PM, Tommaso Cucinotta
> >> <[hidden email]>  wrote:
> >>
> >>> Yes, but AFAICR, there's still a problem: Jack not only pushes the threads
> >>> created by libjack to RT (for which it is easy to identify the Linux TID for
> >>> attaching it to the group), but it also allows the application clients to
> >>> pass
> >>> a *pthread_t* value through the API, in order to raise its priority to
> >>> RT. So, I guess now there's no way to recover the Linux TID from the
> >>> pthread_t, so such a feature wouldn't work anymore.
> >> this is correct, thanks for reminding me/us about that part of the JACK API.
> >>
> >> it used, for example, by clients that need to do RT processing such as
> >> FFT generation, but cannot afford to do it in the thread provided by
> >> JACK.
> > And not all code requiring this does use the Jack API to promote
> > threads to RT. Jconvolver (library) doesn't as it could very
> > well be used without Jack. Most of my other apps run also on ALSA,
> > so they also create their RT threads without using any Jack support
> > (and it's actually trivial once you have a C++ thread class).
>
> Ok. Now, an issue comes immediately to my mind: what RT priority do you
> run these additional threads at, and how does it relate to the
> configured Jack priority, and to the fact that Jack may be actually
> configured with or without RT support, etc. You  need to keep in sync
> things, here, otherwise it doesn't work as you'd expect.
>
> Thanks,
>
>      T.
>
You set them simply a bit lower then jack itself, eg. jack prio -X
we do that for our tuner for example.

void PitchTracker::start_thread()
{
    int                min, max;
    pthread_attr_t     attr;
    struct sched_param  spar;
    int priority, policy;
    pthread_getschedparam(jack_client_thread_id(gx_jack::client),
&policy, &spar);
    priority = spar.sched_priority;
    min = sched_get_priority_min(policy);
    max = sched_get_priority_max(policy);
    priority -= 6; // zita-convoler uses 5 levels
    if (priority > max) priority = max;
    if (priority < min) priority = min;
    spar.sched_priority = priority;
    pthread_attr_init (&attr);
    pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_DETACHED);
    pthread_attr_setschedpolicy (&attr, policy);
    pthread_attr_setschedparam (&attr, &spar);
    pthread_attr_setscope (&attr, PTHREAD_SCOPE_SYSTEM);
    pthread_attr_setinheritsched (&attr, PTHREAD_EXPLICIT_SCHED);
    //pthread_attr_setstacksize (&attr, 0x10000);
    if (pthread_create (&m_pthr, &attr, static_run, (void*)this)) {
            error = true;
    }
    pthread_attr_destroy (&attr);
}


_______________________________________________
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

Tommaso Cucinotta-2
In reply to this post by Dhaval Giani
Il 15/12/2010 20:03, Dhaval Giani ha scritto:
> ram based filesystem. Creating a group is as simple as doing a mkdir,
hmmm..., as weird as, .... I would say :-)
> This means that the cgroup
> will get cpu.rt_period_us microseconds every cpu.rt_period_us
> microseconds.

I have to slightly "correct" this, if you allow me to
(not the runtime/period typo, but smth. more important):
the cgroup will *not be allowed* to run for more than cpu.rt_runtime_us
microseconds every cpu.rt_period_us microseconds. This is not really
the same as *granting* the runtime every period. The latter thing
is done by the IRMOS (a.k.a., edf throttling or Fabio's) deadline scheduler
patch we submitted to the community.

>> 2) If a cpu is specified as in your example, does that
>> mean that RT threads must be bound explicitly to that
>> cpu in order to be accepted ?
> A cpu is not specified anywhere. CPUs are specified only if you are
> using cpusets (but that raises a different problem altogether :-) )

Yes, the "cpu" thing that you see means that we're referring
to the configuration for the "cpu" cgroup controller, i.e., entries
related to the scheduling of processes.

Bye,

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
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 Wed, Dec 15, 2010 at 8:26 PM, Tommaso Cucinotta
<[hidden email]> wrote:

> Il 15/12/2010 20:03, Dhaval Giani ha scritto:
>>
>> ram based filesystem. Creating a group is as simple as doing a mkdir,
>
> hmmm..., as weird as, .... I would say :-)
>>
>> This means that the cgroup
>> will get cpu.rt_period_us microseconds every cpu.rt_period_us
>> microseconds.
>
> I have to slightly "correct" this, if you allow me to
> (not the runtime/period typo, but smth. more important):
> the cgroup will *not be allowed* to run for more than cpu.rt_runtime_us
> microseconds every cpu.rt_period_us microseconds. This is not really
> the same as *granting* the runtime every period. The latter thing
> is done by the IRMOS (a.k.a., edf throttling or Fabio's) deadline scheduler
> patch we submitted to the community.
>

heh. I thought I mentioned that it was the maximum. I guess I am just
a bit hungry and ate those words up instead. Thanks Tommaso!

(And the typo proves that its time I went looking for food :P)

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

Ralf Mardorf
In reply to this post by Alex Stone
On Wed, 2010-12-15 at 21:46 +0300, alex stone wrote:

> On Wed, Dec 15, 2010 at 9:31 PM, Dhaval Giani <[hidden email]> wrote:
> > On Wed, Dec 15, 2010 at 7:19 PM, alex stone <[hidden email]> wrote:
> >> Dhaval,
> >> So as jack users (non-coders), with many of us having invested
> >> hundreds and possibly thousands of hours testing for our modest
> >> community, not to mention the most definitely thousands of hours of
> >> sweat and toil put in by the all too few jack/RT coders who have
> >> valiantly laboured most generously for like minded users in a shared
> >> desire to have great, professional quality, audio/midi/video tools as
> >> viable alternatives to proprietary locked in apps, we are being
> >> reduced to a single label, entitled "Linux User" to satisfy a generic
> >> perception of what someone, somewhere thinks is the definition of what
> >> we "should" be using? Regardless of the limitations this imposes,
> >> which is something we accuse proprietary OS's of?
> >>
> >
> > Not really. As I mentioned, it is quite trivial to turn off all these
> > features. I honestly cannot believe that adding an extra line in a
> > configuration file will turn off users. If it is such a major issue,
> > asking your distro to add that line by default should not be a
> > problem. They should do so. Hey, if there are enough complaints,
> > letting us know upstream will enable us to turn off the policy. I am
> > aware of at least one distro which turns off the default group by
> > default. But unless people let us know, we really cannot do something.
> >
> >> I respectfully wonder if the team that made this decision are aware of
> >> the number of jack/RT users that actually pass through our little
> >> village, or if the decisions being made are in earnest pursuit of a
> >> wider generic user base, are reflective of an honest misunderstanding
> >> of just how important jack/RT apps and infrastructure are for linux
> >> users who would rather enjoy the superb stability of linux as a viable
> >> professional system, over the angst that goes with the "others".
> >>
> >
> > Honestly. I was completely unaware that the jack folks were facing
> > this issue until I saw the cgroups page. What upset me was that this
> > page was put up, but no attempt made to contact the developers who are
> > doing this work. (Not to mention inaccurate information). So I ask
> > this question, are jack users this special case for which the
> > developers should look out for, or like other users they let us know
> > when they are facing issues?
> >
> >> I'm bewildered by the indifference to what i thought was a sizable and
> >> significant chunk of the linux community. It seems i misjudged the
> >> importance and superb performance of a jack based system, over the
> >> rest.
> >>
> >
> > see above. I don't see jack as a special case. It would be very much
> > appreciated if you let us knew you were facing issues. Its not that we
> > want to make life tough for our users. But we need to know that we are
> > making life tough for them :-). This works for most users, yes. If it
> > were not, I am pretty sure we would have had tons of bug reports.
> >
> >> Now it seems we have to start again, yes? Based on what seems ever
> >> increasing perception that all non coding linux users
> >> are......."generic".
> >>
> >> Dhaval, i have no wish to offend you, but it looks as if you've posted
> >> to us as some sort of apologetic afterthought. I appreciate you're in
> >> a bit of a spot with this, but i hope you appreciate this will make
> >> things more challenging for us, and make it even harder to encourage
> >> new users into our village in the linux user community, when we will
> >> have to walk fellow users though additional instructions to try and
> >> get what we already had, and what was already challenging enough to
> >> setup, for new initiates into the linux "way".
> >>
> >> Are we really of so little significance in the wider linux world?

We are. Just an example, Ubuntu Studio does ship with a kernel PREEMPT,
but a kernel PREEMPT RT, because [Phew, snip].

I have given up to make noise, since most of the audio community don't
wish to read my noise, fair play ...

Anyway, I'll left behind this note, after being quiet since month.

It's better to be a lone fighter and be quiet. Linux is a PITA for
professional audio usage. Most people simply switch to other OSs,
without making some noise.

PulseAudio is super, does anybody care that Envy24 user today need to
add cryptic lines to a strange file, to use audio without jack?

$ cat /usr/share/alsa/cards/ICE1712.conf
#
# Configuration for the ICE1712 (Envy24) chip
#
[snip]
<confdir:pcm/front.conf>

ICE1712.pcm.front.0 {
        @args [ CARD ]
        @args.CARD {
                type string
        }
        type route
        ttable.0.0 1
        ttable.1.1 1
        slave.pcm {
                type hw
                card $CARD
        }
        #### fix PA issue ####
        slave.format S32_LE
        slave.channels 10
        ######################
}
[snip]

I could add a list of what to do to get a Linux audio workstation run.
Does anybody guess that there're a lot of gifted musicians out there
wasting time with setting up a computer?

Frequency scaling is one of the issues that is easy to handle for you
and me. Is it easy for averaged musicians and audio engineers?

> >>
> >
> > Not really. Just a bit more noise would be great :-).

Much, much, much more noise.

Does anybody care for MIDI jitter until now?

Nobody cares about what musicians are able to recognise.

Phew?

Bug reports are unwanted etc. pp. ...

JUST, JUST, JUST 2 Cents ...

Ralf

> >
> > Thanks
> > Dhaval
> >
>
> Dhaval,
> So no-one thought, while building this exciting new feature, to do a
> quick test, or at least have a think about, of the significance of the
> impact on jack/RT, given the nature of the feature as a scheduler, and
> what many users think is JACK and jack based apps importance in the
> linux community?
>
> Sort of confirms the indifference to jack/RT as a significant
> component in the linux audio/midi/video world, doesn't it?
>
> I guess there's no going backward from here, but it's a little
> presumptious to assume non-coding users are going to hang around
> kernel central, in the hope that we'll understand what you're about to
> do, and fire a message back to those who do understand it, given
> they're already working like trojans, (The human variety), for our
> benefit.
>
> If we don't yell, we don't get considered?
>
> I appreciate you took the time to respond, so i won't add anything else.
>
> Regards,
>
> Alex.
> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


_______________________________________________
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

Tommaso Cucinotta-2
In reply to this post by Hermann Meyer
Il 15/12/2010 20:22, hermann ha scritto:
> You set them simply a bit lower then jack itself, eg. jack prio -X
> we do that for our tuner for example.

got it, thanks. Still a (side) question, sorry:

>      pthread_getschedparam(jack_client_thread_id(gx_jack::client),
> &policy,&spar);
>      priority = spar.sched_priority;
>      min = sched_get_priority_min(policy);
>      max = sched_get_priority_max(policy);
>      priority -= 6; // zita-convoler uses 5 levels
>      if (priority>  max) priority = max;
>      if (priority<  min) priority = min;
>      spar.sched_priority = priority;
>      pthread_attr_init (&attr);
>      pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_DETACHED);
>      pthread_attr_setschedpolicy (&attr, policy);
>      pthread_attr_setschedparam (&attr,&spar);

this only works if Jack is running at RT prio, right ? Because, if it is
running SCHED_OTHER, then I would expect the retrieved priority is 0 and
it makes no sense to decrease it (well, you compare with min and max
which would be both 0, so you wouldn't decrease in such case). However,
if you actually meant to change the nice level in such a case, then you
would have been supposed to use the nice(2) syscall, wouldn't you ?

Thx,

     T.

--
Tommaso Cucinotta, Computer Engineering PhD, Researcher
ReTiS Lab, Scuola Superiore Sant'Anna, Pisa, Italy
Tel +39 050 882 024, Fax +39 050 882 003
http://retis.sssup.it/people/tommaso

_______________________________________________
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

Jack O'Quin
In reply to this post by Dhaval Giani
On Wed, Dec 15, 2010 at 1:07 PM, Dhaval Giani <[hidden email]> wrote:
>> 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.

Why make changes to kernel realtime scheduling without first doing a
careful study of how actual realtime applications work?

Is it our job to explain these applications to you? Or, your job to
understand the problem before "solving" it?

>> 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.

You didn't understand that kernel changes only affect real users after
18 to 24 months delay? No wonder Linux kernel development often
appears to happen in a vacuum.

Implicit in this whole discussion is the assumption that there exist
applications for which the cgroups scheduling is useful. Since it
clearly does not work for realtime audio, I am curious to know what it
*is* good for. Can you please post a link to the rationale?
--
 joq
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
1234