Re: [LAD] Realtime threads and security

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: Olivier Guilyardi <list@...>
Cc: <linux-audio-dev@...>
Date: Friday, February 18, 2011 - 1:43 pm

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB052DA3E25BB58F3451AB23D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 02/17/2011 09:40 PM, Olivier Guilyardi wrote:

> The one thing about Android is that it has a strict security model. Eve=
ry app is

example
And of

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

--------------enigB052DA3E25BB58F3451AB23D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJNXneCAAoJEFYpgV2RoepcTz0P/jDjvraBUOY1Kz3XIK7f3tBl
PxremT2roy919e+QA4UsPR9nHY/1Ty2GBaY+EvvRrb1h3AQ0JK9jymmK7Z9CzHec
NFZ+DVMx9HKcauPwfyR/TB2/vmyEkvmvh4Ad9B7malmqRZb7ngc5aJ0Z8W5lS+Tc
+tsVlgB6OUKhIz0iNtyUwDJ6biQZchqgket8JVrDmzAai5BuqlpXC18X/xy5XUqa
nA/7tSByBU4A0o1b++/6EnXor5iNW1+xGTTJ1nliQbIWhQh7YgEi4Sww1YuKiQAi
fWs9ZodHyJvyb7Oa3+5EWRqDNRqVHBNsQIo7y1u73IraFmTH7WYbrO286nldWrbR
TTZYoPxT5+hNJLW04vNmgyvK6+hlplkj0Dvk7+OX4wyH8BSOTEpyozzXBHAovTUY
/r2k9MlWIxsYWC7i74TtlIXQmvgvjH/vcLMDnbwe4d51NHFJSaGOJQ+K7snSdkTB
kbMtEPr0i+MTGZCnf2NGTGdiLK9p4Z09kinnDvw2wVEcbTqgWfTNiCQVRcFScD1r
yWnw1Vc5t/5jUg3GEbWbijMWKJGeD+UmudEguesijufuTrlTSctFCgm4zbEVYjkw
l+OtNJmglxDYztQ1ug4tgXGFHwAzH41ewUrbhMgJkSl37nXLkxF4RTwDwdhbzbEA
1aDEpQnw8aEUzbmAL3OT
=XC2/
-----END PGP SIGNATURE-----

--------------enigB052DA3E25BB58F3451AB23D--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Realtime threads and security, Olivier Guilyardi, (Thu Feb 17, 8:40 pm)
Re: [LAD] Realtime threads and security, Daniel Poelzleithner, (Fri Feb 18, 1:43 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Wed Feb 23, 10:10 am)
Re: [LAD] Realtime threads and security, Daniel Poelzleithner, (Wed Feb 23, 5:24 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 25, 3:23 pm)
Re: [LAD] Realtime threads and security, Paul Davis, (Fri Feb 25, 3:29 pm)
Re: [LAD] Realtime threads and security, torbenh, (Fri Feb 25, 3:56 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 25, 3:54 pm)
Re: [LAD] Realtime threads and security, Paul Davis, (Fri Feb 25, 4:32 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 25, 4:40 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 25, 4:31 pm)
Re: [LAD] Realtime threads and security, Paul Davis, (Fri Feb 25, 4:33 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 25, 4:49 pm)
Re: [LAD] Realtime threads and security, Paul Davis, (Fri Feb 25, 4:54 pm)
Re: [LAD] Realtime threads and security, Paul Davis, (Thu Feb 17, 8:48 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Thu Feb 17, 9:27 pm)
Re: [LAD] Realtime threads and security, Robin Gareus, (Thu Feb 17, 9:54 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Wed Feb 23, 10:22 am)
Re: [LAD] Realtime threads and security, Robin Gareus, (Wed Feb 23, 7:28 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Thu Feb 24, 2:59 pm)
Re: [LAD] Realtime threads and security, Robin Gareus, (Thu Feb 24, 6:01 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Thu Feb 24, 7:09 pm)
Re: [LAD] Realtime threads and security, Fons Adriaensen, (Thu Feb 17, 10:04 pm)
Re: [LAD] Realtime threads and security, Olivier Guilyardi, (Fri Feb 18, 12:17 pm)
Re: [LAD] Realtime threads and security, torbenh, (Fri Feb 18, 11:19 am)
Re: [LAD] Realtime threads and security, Paul Davis, (Thu Feb 17, 9:55 pm)