17 Feb
2011
17 Feb
'11
9:40 p.m.
Hi everyone,
I am currently spending a lot of time working on Android, and on the andraudio
mailing list [1] we are discussing about possible improvements to the internal
Android audio system. Currently, latencies are very high, over 100ms, and we're
looking for ways to improve the situation.
In my opinion this can't be achieved on Linux without realtime scheduling. On
Android, there's something called audioflinger which acts as a sound server, and
apps act as clients of this server. The server and clients run in distinct
processes. What I'm thinking about is having a realtime thread within the
server, as well as another realtime thread in the (each) client.
The one thing about Android is that it has a strict security model. Every app is
considered potentially harmful and is thus "sandboxed". Here, this for example
means that apps can lower their threads priority, but not increase it. And of
course they can only use non-realtime scheduling.
On desktops, for instance using JACK, apart from a few multimedia distributions,
realtime permissions are not granted by default to normal users. And when one
enables it, security is usually not a primary concern AFAIK. If a piece of
software happens to crash the system when running in realtime, the user may just
uninstall the buggy software, etc..
But on phones, this is critical, for example if the system crashes while you're
waiting for a call. So, on Android, the security policies are strict. But this
could certainly be necessary to plenty of other Linux usages.
Now my question is: how to allow user-space apps to use realtime scheduling for
one of their threads without compromising the overall security?
For example, in man sched_setcheduler() I see SCHED_RR, and "Everything
described above for SCHED_FIFO also applies to SCHED_RR, except that each
process is only allowed to run for a maximum time quantum".
Would this help and be sufficient? Would there need to have some kind of
watchdog/monitor running with SCHED_FIFO scheduling to prevent realtime client
threads from consuming too much resources?
Or is there some other ways to achieve this? Some kernel patch maybe?
Thanks in advance
[1] http://music.columbia.edu/mailman/listinfo/andraudio
Olivier
17 Feb
17 Feb
9:48 p.m.
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi <list(a)samalyse.com> wrote:
Or is there some other ways to achieve this? Some
kernel patch maybe?
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a couple of
lines, at most.
whether this a security risk depends on which other parts of the
kernel android uses. on regular linux, its no longer possible for any
process to steal all the CPU time. there are files in the /proc/sys
filesystem that control the amount available.
note that patching the kernel in this way means that any process by
any user can get SCHED_FIFO so its hardly clear that this is actually
any better than using rlimits from a security perspective.
10:27 p.m.
On 02/17/2011 09:48 PM, Paul Davis wrote:
On Thu, Feb 17, 2011 at 3:40 PM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a couple of
lines, at most.
whether this a security risk depends on which other parts of the
kernel android uses. on regular linux, its no longer possible for any
process to steal all the CPU time. there are files in the /proc/sys
filesystem that control the amount available.
note that patching the kernel in this way means that any process by
any user can get SCHED_FIFO so its hardly clear that this is actually
any better than using rlimits from a security perspective.
I know that patching is not a requirement anymore for realtime on Linux. But I
was just asking about some possible security enhancement patch.
What are those files in /proc/sys that you mention?
Also I'm a bit confused about rlimits. IIUC, realtime processes always run
before non-realtime processes. And the realtime priority as set with
set_rlimits() only affects the priority of realtime processes between each
other. It doesn't seem to affect the priority between realtime and non-realtime
processes.
I've been told than on OSX, when a process runs in realtime, it is only allowed
to use a certain ratio of CPU time. And if it goes over this limit, it loses its
priority. Is there something comparable on Linux? Maybe with the files in
/proc/sys that you mention?
What I'm looking for is some way to say: ok, this thread can run in realtime,
but if it ever uses more than 10% of CPU time it will lose realtime priority.
Aside of that, what about locks? I've many times been told that one mustn't do
anything that could block in a realtime thread. What are the consequences of
that? Could a malicious app freeze the system by blocking in a realtime thread?
--
Olivier
10:53 p.m.
On 02/17/2011 10:27 PM, Olivier Guilyardi wrote:
On 02/17/2011 09:48 PM, Paul Davis wrote:
Hi Olivier,
Paul must have been talking about
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
<kernel-source>/Documentation/scheduler/sched-rt-group.txt
On Thu, Feb 17, 2011 at 3:40 PM, Olivier
Guilyardi <list(a)samalyse.com> wrote:
in earlier versions of 2.6, the kernel patch to allow SCHED_FIFO for
everyone was incredibly simple. i recall kjetil posting a couple of
lines, at most.
whether this a security risk depends on which other parts of the
kernel android uses. on regular linux, its no longer possible for any
process to steal all the CPU time. there are files in the /proc/sys
filesystem that control the amount available.
note that patching the kernel in this way means that any process by
any user can get SCHED_FIFO so its hardly clear that this is actually
any better than using rlimits from a security perspective.
I know that patching is not a requirement anymore for realtime on Linux. But I
was just asking about some possible security enhancement patch.
What are those files in /proc/sys that you mention? Also I'm a bit confused about rlimits. IIUC,
realtime processes always run
before non-realtime processes. And the realtime priority as set with
set_rlimits() only affects the priority of realtime processes between each
other. It doesn't seem to affect the priority between realtime and non-realtime
processes.
I've been told than on OSX, when a process runs in realtime, it is only allowed
to use a certain ratio of CPU time. And if it goes over this limit, it loses its
priority. Is there something comparable on Linux? Maybe with the files in
/proc/sys that you mention?
not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
scheduling time. To limit it per process you'll need cgroups.
What I'm looking for is some way to say: ok, this
thread can run in realtime,
but if it ever uses more than 10% of CPU time it will lose realtime priority.
Aside of that, what about locks? I've many times been told that one mustn't do
anything that could block in a realtime thread. What are the consequences of
that? Could a malicious app freeze the system by blocking in a realtime thread?
--
Olivier
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
10:55 p.m.
On Thu, Feb 17, 2011 at 4:53 PM, Robin Gareus <robin(a)gareus.org> wrote:
> Aside of that, what about locks? I've many
times been told that one mustn't do
> anything that could block in a realtime thread. What are the consequences of
> that? Could a malicious app freeze the system by blocking in a realtime thread?
it poses no risks to anything except itself if it does that. blocking
in an RT thread matters to the thread, not to anything else.
to demote RT threads that are doing too much you'd need a user-space
watchdog like das_watchdog
11:04 p.m.
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
Still this provides protection against any RT-process that goes
out of control. If the limit is exceeded, all RT procs will be
blocked for the next sched_rt_period_us (default seems to be 1s),
which should give you the opportunity to kill the offending process.
There seem to be some restrictions on runtime / period, this must
be between 0.95 and 1.00 or zero. Which means that in order to adjust
period you first need to set runtime to zero, then adjust period, then
reset runtime to a value within the accepted range.
--
FA
I've been told than on OSX, when a process
runs in realtime, it is only allowed
to use a certain ratio of CPU time. And if it goes over this limit, it loses its
priority. Is there something comparable on Linux? Maybe with the files in
/proc/sys that you mention?
not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
scheduling time. To limit it per process you'll need cgroups. 
18 Feb
18 Feb
12:18 p.m.
On Thu, Feb 17, 2011 at 10:04:31PM +0000, Fons Adriaensen wrote:
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus
wrote:
if that restriction exists, its a bug.
i remember that i successfully set the ratio to 0.1 ...
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
Still this provides protection against any RT-process that goes
out of control. If the limit is exceeded, all RT procs will be
blocked for the next sched_rt_period_us (default seems to be 1s),
which should give you the opportunity to kill the offending process.
There seem to be some restrictions on runtime / period, this must
be between 0.95 and 1.00 or zero. Which means that in order to adjust
period you first need to set runtime to zero, then adjust period, then
reset runtime to a value within the accepted range. I've been told than on OSX, when a process
runs in realtime, it is only allowed
to use a certain ratio of CPU time. And if it goes over this limit, it loses its
priority. Is there something comparable on Linux? Maybe with the files in
/proc/sys that you mention?
not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
scheduling time. To limit it per process you'll need cgroups.
--
FA
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
1:17 p.m.
On 02/17/2011 11:04 PM, Fons Adriaensen wrote:
On Thu, Feb 17, 2011 at 10:53:54PM +0100, Robin Gareus
wrote:
> /proc/sys/kernel/sched_rt_runtime_us
> /proc/sys/kernel/sched_rt_period_us
>
>> I've been told than on OSX, when a process runs in realtime, it is only
allowed
>> to use a certain ratio of CPU time. And if it goes over this limit, it loses its
>> priority. Is there something comparable on Linux? Maybe with the files in
>> /proc/sys that you mention?
> not exactly. /proc kernel.sched_rt_runtime_us globally limits realtime
> scheduling time. To limit it per process you'll need cgroups.
Thank you. This, as described in Documentation/scheduler/sched-rt-group.txt is
exactly what I was looking for. A cgroup may indeed be required for all clients,
with another cgroup for the sound server.
Still this provides protection against any RT-process
that goes
out of control. If the limit is exceeded, all RT procs will be
blocked for the next sched_rt_period_us (default seems to be 1s),
which should give you the opportunity to kill the offending process.
Reading sched-rt-group.txt it seems to me like if the limit is exceeded, RT
processes are preempted until the end of the period, which sounds very good. I
assume that's what you mean by "blocked".
If the sound server is in its own cgroup then system audio shouldn't be affected
by bogus user-space clients. But, in the context of Android, I'm a bit worried
about the fact that one bogus realtime app could affect all other running
realtime apps. On Android, there are background processes, and users could be
misled if they see that a foreground app starts to malfunction, when it's
actually caused by a background process.
I think that ideally, the system should detect the offending app, freeze it, and
pop up a dialog to inform the user. That's already the way it works when an
application is not responding or crashes.
I am not sure how that would be feasible. Maybe with das_watchdog as mentioned
by Paul or something custom/similar?
Alternatively, the system could refuse to run more than one realtime client at
the same time. But how to do that? Maybe by having the sound server dynamically
assign the client to a cgroup only if possible, or refuse and report an error to
the client otherwise?
--
Olivier
23 Feb
23 Feb
11:22 a.m.
Hi,
On 02/17/2011 10:53 PM, Robin Gareus wrote:
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
<kernel-source>/Documentation/scheduler/sched-rt-group.txt
There's something which confuses me. But I'm not sure how this realtime period
settings relate to the audio I/O period.
On Android, the closest that one can get to hardware in a more or less portable
way is libaudio [1]. It's Android's audio HAL. This API exposes blocking read()
and write() calls, with fixed buffer sizes (input and output buffer sizes
generally do not match, but that's another problem).
So, this may be a silly/newbie question, but can one access this blocking API
from a realtime thread? What will happen when it blocks? How does the read/write
period relate to sched_rt_period_us?
[1] http://source.android.com/porting/audio.html
--
Olivier
8:28 p.m.
On 02/23/2011 11:22 AM, Olivier Guilyardi wrote:
Hi,
On 02/17/2011 10:53 PM, Robin Gareus wrote:
It only does iff the audio-I/O thread (or process) is executed with
realtime privileges (`man chrt` - man `pthread_setschedparam` ).
if you have a RT_PREEMPT kernel you can also raise the priority of the
audio-device interrupt handler.
Well, it's a bit more complex than that.. not sure if you can go that
way on Android easily.
/proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
<kernel-source>/Documentation/scheduler/sched-rt-group.txt
There's something which confuses me. But I'm not sure how this realtime period
settings relate to the audio I/O period. On Android, the closest that one can get to hardware
in a more or less portable
way is libaudio [1]. It's Android's audio HAL. This API exposes blocking read()
and write() calls, with fixed buffer sizes (input and output buffer sizes
generally do not match, but that's another problem).
So, this may be a silly/newbie question, but can one access this blocking API
from a realtime thread? What will happen when it blocks? How does the read/write
period relate to sched_rt_period_us?
[1] http://source.android.com/porting/audio.html
--
Olivier
24 Feb
24 Feb
3:59 p.m.
Hello Robin,
On 02/23/2011 08:28 PM, Robin Gareus wrote:
On 02/23/2011 11:22 AM, Olivier Guilyardi wrote:
Hmm.. realtime privileges are a given in this discussion. Yes, the idea is to
have the audio I/O thread run in realtime, and access the audio hardware through
the Android audio HAL, namely libaudio, instead of say, ALSA.
ALSA actually is the backend of libaudio on certain devices, but only a
minority. So, for more portability, I'm investigating whether it would be
possible to read and write using the libaudio API from a realtime thread.
Hi,
On 02/17/2011 10:53 PM, Robin Gareus wrote:
It only does iff the audio-I/O thread (or process) is executed with
realtime privileges (`man chrt` - man `pthread_setschedparam` ). /proc/sys/kernel/sched_rt_runtime_us
/proc/sys/kernel/sched_rt_period_us
<kernel-source>/Documentation/scheduler/sched-rt-group.txt
There's
something which confuses me. But I'm not sure how this realtime period
settings relate to the audio I/O period. if you have a RT_PREEMPT kernel you can also raise the
priority of the
audio-device interrupt handler.
I need to look at that, but I'm not sure if this is relevant in the case of
libaudio, as it is when using ALSA. The audio hardware which is integrated into
these all-in-one chips seems to be sometimes very different from conventional
soundcards. And in many cases there are rather non standard kernel drivers under
libaudio. So I'm not sure whether one can think in terms of interrupts on
Android mobile systems. But I suppose it makes sense in the majority of cases.
Well, it's a bit more complex than that.. not sure
if you can go that
way on Android easily.
Since you mention realtime privileges above, I suspect some confusion here.
This discussion is not about capturing and playing audio using the Android
public API. It is about improving low level Android audio support, by:
- either writing some patches for the mainstream Android source code
- or dropping some external module on systems where the user has acquired
superuser privileges (rooted devices).
For the later, what module? Well, this could for example be JACK. This should be
possible to a certain extent.
Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?
> On Android, the closest that one can get to
hardware in a more or less portable
> way is libaudio [1]. It's Android's audio HAL. This API exposes blocking
read()
> and write() calls, with fixed buffer sizes (input and output buffer sizes
> generally do not match, but that's another problem).
>
> So, this may be a silly/newbie question, but can one access this blocking API
> from a realtime thread? What will happen when it blocks? How does the read/write
> period relate to sched_rt_period_us?
>
> [1] http://source.android.com/porting/audio.html
--
Olivier
7:01 p.m.
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote:
Hello Robin,
Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?
mmh. it depends on how the blocking is done. If it is a spin-lock it
will consume CPU and block other processes which are running at lower
priority in the meantime (but only up to sched_rt_runtime_us per second.
Other processes won't starve). Is there a poll (or select) function
available as part of the libaudio API?
If the i/o block waits for a signal (e.g. IRQ), it will work just fine.
> On
Android, the closest that one can get to hardware in a more or less portable
> way is libaudio [1]. It's Android's audio HAL. This API exposes blocking
read()
> and write() calls, with fixed buffer sizes (input and output buffer sizes
> generally do not match, but that's another problem).
>
> So, this may be a silly/newbie question, but can one access this blocking API
> from a realtime thread? What will happen when it blocks? How does the read/write
> period relate to sched_rt_period_us?
>
> [1] http://source.android.com/porting/audio.html
--
Olivier
8:09 p.m.
On 02/24/2011 07:01 PM, Robin Gareus wrote:
On 02/24/2011 03:59 PM, Olivier Guilyardi wrote:
I don't think there are spin locks, which would say loop until some data becomes
available, etc.. The libaudio implementation is provided by the device and/or
the harware platform (main chip) manufacturer(s), so it's rather opaque. Some of
these implementations are open source (http://android.git.kernel.org/), but they
can differ a lot.
But to prevent problem in case some libaudio implementations use a spin lock,
then the audio server, audioflinger, could have limited realtime runtime, with
sched_rt_runtime_us, as you mention (at first I was only thinking about this for
the audio clients, not the server).
I don't know about a select function exposed by libaudio. There are only
blocking read() and write() functions AFAIK.
Hello Robin,
Now, say I'm only focusing on playback now. Is there something wrong with
calling a blocking output API from a realtime thread as I ask below?
mmh. it depends on how the blocking is done. If it is a spin-lock it
will consume CPU and block other processes which are running at lower
priority in the meantime (but only up to sched_rt_runtime_us per second.
Other processes won't starve). Is there a poll (or select) function
available as part of the libaudio API? If the i/o block waits for a signal (e.g. IRQ), it
will work just fine.
That sounds good.
In the implementations that I saw so far, when it's not ALSA, it seems to be
some kind of OSS file-based interface. So I think that's quite safe to assume
that read/write operation are backed by an interrupt.
The one catch is that in all libaudio implementations that I saw, some mutexes
get locked in both read() and write(). Is this a problem?
I just looked into JACK1, and I see some pthread mutex being locked in
oss_driver_read(), in drivers/oss/oss_driver.c. What happens in case of a mutex
lock? Is there a context switch?
--
Olivier
18 Feb
18 Feb
2:43 p.m.
On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:
The one thing about Android is that it has a strict
security model. Every app is
considered potentially harmful and is thus "sandboxed". Here, this for example
means that apps can lower their threads priority, but not increase it. And of
course they can only use non-realtime scheduling.
I have written a dynamic system optimizer for linux called ulatencyd. I
stumbled more by accident over rt issues my self. I use dynamic cgroups
to adjust the resources of the system to what heuristic rules think the
user expects. At least in the default desktop configuration but you can
actually optimise every system to every load.
I mainly use cgroups to group processes which get different parameters
like cpu.shares and some other values. you can use cgroups to give
strict RT slices. In fact, if you want processes to be able to get rt
you have to handle them to, when CONFIG_RT_GROUP_SCHED is set.
It is a little bit tricky and it's kind of a hack, how ulatencyd does
it, because there is no notification in into userspace when rt
scheduling is set on a thread. (There is not even a hook in the kernel
execpt the secruity module).
What ulatencyd does is to give most groups a cpu.rt_runtime_us of 1,
this is way to less to actually do rt work, but allows a process to set
rt on a thread. The current scheduler config moves processes that have
realtime threads into a rt group that have enough cpu.rt_runtime_us to
do their work, but not enough to pull down a system.
There are some drawbacks, as I don't get notifications in thread
changes, the process is only looked at in a iteration cycle. If a
process starts it's rt thread shortly after booting up, everything is
fine, as long as he doesn't instantly complain about the bandwidth
assigned. jackd for example starts up quite nicely, so does pulseaudio.
If a process starts his rt thread very late, the rescheduling could take
a iteration interval which is 10 seconds currently.
If there is a rule, that marks the process with a flag "sched.rt" it
will get moved into the rt group as soon as ulatencyd runs the process,
thats quite after delay of 1s (default). I'm thinking about adding a
special very early match list that allows to minimise this delay. It
exists because many normal processes are just very short living and it's
useless to schedule them in the first place.
If you are a process, you can put yourself into the rt group by doing in
dbus call and mark it as sched.rt and kick a schedling on the process,
this way you will instantly end up in the rt group.
Now, what you can do if you have no trust in processes at all is, to
create dynamic cgroups with carefully calculated cpu.rt_runtime_us
values for the processes. If you have trusted processes, you may give
them seperate cgroups with fixed runtimes, like for example your mixer
process. But remember: you can't overcommit rt_runetime_us and they will
not borrow their rt if they don't use it.
kind regards
Daniel
23 Feb
23 Feb
11:10 a.m.
Hello Daniel,
thanks for sharing your experience.
On 02/18/2011 02:43 PM, Daniel Poelzleithner wrote:
On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:
I have written a dynamic system optimizer for linux called ulatencyd. I
stumbled more by accident over rt issues my self. I use dynamic cgroups
to adjust the resources of the system to what heuristic rules think the
user expects. At least in the default desktop configuration but you can
actually optimise every system to every load.
I assume it's here:
https://github.com/poelzi/ulatencyd/
Now, what you can do if you have no trust in processes
at all is, to
create dynamic cgroups with carefully calculated cpu.rt_runtime_us
values for the processes. If you have trusted processes, you may give
them seperate cgroups with fixed runtimes, like for example your mixer
process. But remember: you can't overcommit rt_runetime_us and they will
not borrow their rt if they don't use it.
The dynamic cgroups solution seems good.
On Android there basically is one priviledged and trusted audio process,
audioflinger, the sound server, which performs mixing and access the hardware.
All audio clients are untrusted. I think there is a need to both assign a
careful cpu.rt_runtime_us to each client but also to limit the number of clients
which can run at the same time. This would allow to keep the CPU time assigned
to all clients within a certain quota, but also to prevent clients from fighting
with each other for realtime bandwidth.
Can you limit the maximum number of realtime processes with ulatencyd?
--
Olivier
6:24 p.m.
On 02/23/2011 11:10 AM, Olivier Guilyardi wrote:
The dynamic cgroups solution seems good.
On Android there basically is one priviledged and trusted audio process,
audioflinger, the sound server, which performs mixing and access the hardware.
All audio clients are untrusted. I think there is a need to both assign a
careful cpu.rt_runtime_us to each client but also to limit the number of clients
which can run at the same time. This would allow to keep the CPU time assigned
to all clients within a certain quota, but also to prevent clients from fighting
with each other for realtime bandwidth.
Can you limit the maximum number of realtime processes with ulatencyd?
Yes, that should be possible, even i never used that. So, you want a
first come first get policy ?
There is no nice api for detecting the number of processes in a group
but i will add one as i think it's a valid decision to consider. There
is no per se limit of processes in a group, in fact: there is no way to
limit processes numbers anyhow, unfortunately. Makes it very hard to
write write a fork bomb protector ;-)
But, you can of course just stop moving processes into a group.
Yesterday i added a instant filter functionality that allows you with
witelists to move processes extremly quickly. This is required for some
daemons that request realtime and then messure the cpu time they get to
test if it's enough for running smoothly. Those problematic processes
must be whitelisted because the normal delay mechanism would schedule
them to late, as many processes started are just short running and
looking at them is just a waste of cpu time.
kind regards
Daniel
25 Feb
25 Feb
4:23 p.m.
On 02/23/2011 06:24 PM, Daniel Poelzleithner wrote:
On 02/23/2011 11:10 AM, Olivier Guilyardi wrote:
Yes, that's the idea. Maybe limit the number of audio clients to a few ones.
The dynamic cgroups solution seems good.
On Android there basically is one priviledged and trusted audio process,
audioflinger, the sound server, which performs mixing and access the hardware.
All audio clients are untrusted. I think there is a need to both assign a
careful cpu.rt_runtime_us to each client but also to limit the number of clients
which can run at the same time. This would allow to keep the CPU time assigned
to all clients within a certain quota, but also to prevent clients from fighting
with each other for realtime bandwidth.
Can you limit the maximum number of realtime processes with ulatencyd?
Yes, that should be possible, even i never used that. So, you want a
first come first get policy ? There is no nice api for detecting the number of
processes in a group
but i will add one as i think it's a valid decision to consider. There
is no per se limit of processes in a group, in fact: there is no way to
limit processes numbers anyhow, unfortunately. Makes it very hard to
write write a fork bomb protector ;-)
But, you can of course just stop moving processes into a group.
Yesterday i added a instant filter functionality that allows you with
witelists to move processes extremly quickly. This is required for some
daemons that request realtime and then messure the cpu time they get to
test if it's enough for running smoothly. Those problematic processes
must be whitelisted because the normal delay mechanism would schedule
them to late, as many processes started are just short running and
looking at them is just a waste of cpu time.
In the case of Android, here's what I imagine:
- a client program asks for (realtime) audio access
- the audio server verifies if there aren't too many clients
- from that, the server either allows or denies access
- in case of a denial the client program can display a meaningful error
One thing is that each client runs under a different UID. This is part of app
sandboxing. There isn't any predetermined groups of users who can or can't
access audio (oh well there is a permission system for that, but it's another
question).
Basically, any app could request audio access, and ulatencyd or whatever does
the same job would have to be rather tightly integrated into the sound server,
and move the requesting app to a realtime cgroup if it's possible, or deny
access and return an error.
Well, you could imagine that ulatencyd and the sound server are distinct and
that the client program must connect to both to achieve realtime + audio access.
But let's take JACK for example. It handles setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
This would for example result in a new error reported by jack_client_open() in
case realtime permissions can't be granted because there are too many clients, etc..
--
Olivier
4:29 p.m.
On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
But let's take JACK for example. It handles
setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
with what JACK does. ulatencyd appearst to me concerned entirely with
desktop latency and the notion that the "current app" (as represented
by some form of ongoing user interaction) should be the most
responsive. this has nothing whatsoever to do with the realtime
scheduling that JACK is concerned with.
specifically, what JACK does is per-thread, and more significantly its either:
* for threads that it creates (inside libjack) AND knows that they
need to be RT
* for threads that the client specifically asks to be RT
you can't do this stuff on a per-process level.
4:54 p.m.
On 02/25/2011 04:29 PM, Paul Davis wrote:
On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
I was only supposing the integration of ulatencyd with JACK to illustrate my
points. I was not saying that it's necessary a good idea.
But let's take JACK for example. It handles
setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
with what JACK does. ulatencyd appearst to me concerned entirely with
desktop latency and the notion that the "current app" (as represented
by some form of ongoing user interaction) should be the most
responsive. this has nothing whatsoever to do with the realtime
scheduling that JACK is concerned with. specifically, what JACK does is per-thread, and more
significantly its either:
* for threads that it creates (inside libjack) AND knows that they
need to be RT
* for threads that the client specifically asks to be RT
you can't do this stuff on a per-process level.
Let me rephrase my idea.
Let's imagine that JACK runs as a privilege user, which in addition of having
realtime privileges, is also able to assign other processes to given cgroups and
adjust their sched_rt_runtime_us and sched_rt_period_us dynamically. Which is
the kind of thing which ulatencyd does IIUC.
But let's forget about ulatencyd for a second.
Let's now consider that clients runs as user(s) which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this scenario could also
refuse connections if it considers that there isn't enough resources.
Doesn't this make sense to a certain extent?
Wouldn't this be an improvement in regard to security?
--
Olivier
5:31 p.m.
On 02/25/2011 04:53 PM, Olivier Guilyardi wrote:
Wouldn't this be an improvement in regard to
security?
About this, security really doesn't seem like a pointless question to me.
Otherwise, why would all major distributions grant absolutely no realtime
privileges/runtime by default? Reading the JACK FAQ and editing some obscure
config file to gain realtime privileges isn't exactly user-friendly.. You don't
need that kind of thing for realtime audio on OSX for example.
--
Olivier
5:33 p.m.
On Fri, Feb 25, 2011 at 11:31 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
On 02/25/2011 04:53 PM, Olivier Guilyardi wrote:
the point is that both OS X and contemporary linux have mechanisms
that prevent RT scheduling from locking up the system.
linux distributions have not adapted to this reality and thus they
still continue to make RT scheduling inaccessible to users by default.
Wouldn't this be an improvement in regard to
security?
About this, security really doesn't seem like a pointless question to me.
Otherwise, why would all major distributions grant absolutely no realtime
privileges/runtime by default? Reading the JACK FAQ and editing some obscure
config file to gain realtime privileges isn't exactly user-friendly.. You don't
need that kind of thing for realtime audio on OSX for example.
5:49 p.m.
On 02/25/2011 05:33 PM, Paul Davis wrote:
the point is that both OS X and contemporary linux
have mechanisms
that prevent RT scheduling from locking up the system.
linux distributions have not adapted to this reality and thus they
still continue to make RT scheduling inaccessible to users by default.
Maybe that's because such security mechanism are too young in Linux?
Or maybe that any system-wide RT privileges are considered too dangerous?
In these circumstances, maybe that a JACK specific solution could make sense. It
would only need jackd to run as a privileged user (I don't mean root). Maybe
that this would make its way into major distributions more easily than
system-wide RT privileges.
Although I think that granting system-wide RT privileges with a limited runtime
sounds like the best solution. But maybe that this mechanism isn't considered
mature yet.
--
Olivier
5:54 p.m.
On Fri, Feb 25, 2011 at 11:49 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
In these circumstances, maybe that a JACK specific
solution could make sense. It
would only need jackd to run as a privileged user (I don't mean root). Maybe
that this would make its way into major distributions more easily than
system-wide RT privileges.
this is the *existing* solution. the "priviledged user" is the one who
is granted access to SCHED_FIFO and memlock. its that simple.
5:32 p.m.
On Fri, Feb 25, 2011 at 10:53 AM, Olivier Guilyardi <list(a)samalyse.com> wrote:
Let's now consider that clients runs as user(s)
which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this scenario could also
refuse connections if it considers that there isn't enough resources.
sure, but granting RT privs to a client is not the goal. you want to
actually set the scheduling policy for specific threads.
5:40 p.m.
On 02/25/2011 05:32 PM, Paul Davis wrote:
On Fri, Feb 25, 2011 at 10:53 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
Hmm, then..
1. a program calls jack_client_open()
2. libjack talks to jackd to request RT privs
3. jackd grants privs, with cgroup, runtime, period, etc..
4. libjack receives a success code from jackd
5. libjack sets the scheduling policy on the relevant threads
If at 4., jackd receives an error code, jack_client_open() terminates and
returns an error status.
But maybe that this is too much complication, where setting a global RT
runtime/period is maybe sufficient, and could possibly become the default in
major distributions. Not sure why it's done been done yet though.
--
Olivier
Let's now consider that clients runs as
user(s) which do not have realtime
privileges by default, but that it's JACK which grant them such privileges and
assign them a certain CPU time share dynamically. In this scenario could also
refuse connections if it considers that there isn't enough resources.
sure, but granting RT privs to a client is not the goal. you want to
actually set the scheduling policy for specific threads.
4:56 p.m.
On Fri, Feb 25, 2011 at 10:29:45AM -0500, Paul Davis wrote:
On Fri, Feb 25, 2011 at 10:23 AM, Olivier Guilyardi
<list(a)samalyse.com> wrote:
also if cgroups on the system are properly configured, all the server
side needs to do is:
echo "$TID" >/mnt/cgroups/cpu/rt_goup/tasks
i dont think you need a lua interpreter for that :>
But let's take JACK for example. It handles
setting up realtime scheduling
transparently when one creates a jack client. There isn't any extra step
necessary. As a supposition, could you imagine that ulatencyd integrates tightly
into JACK to provide fine-grained per-client realtime permissions?
ulatencyd is, IMHO, a complete red-herring here. it has nothing to do
with what JACK does. ulatencyd appearst to me concerned entirely with
desktop latency and the notion that the "current app" (as represented
by some form of ongoing user interaction) should be the most
responsive. this has nothing whatsoever to do with the realtime
scheduling that JACK is concerned with.
specifically, what JACK does is per-thread, and more significantly its either:
* for threads that it creates (inside libjack) AND knows that they
need to be RT
* for threads that the client specifically asks to be RT
you can't do this stuff on a per-process level. _______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
--
torben Hohn
5048
days inactive
5056
days old
linux-audio-dev@lists.linuxaudio.org
25 comments
6 participants
participants (6)
-
Daniel Poelzleithner -
Fons Adriaensen -
Olivier Guilyardi -
Paul Davis -
Robin Gareus -
torbenh