<div class="gmail_quote">2011/2/14 Andrey Borzenkov <span dir="ltr">&lt;<a href="mailto:arvidjaar@mail.ru">arvidjaar@mail.ru</a>&gt;</span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">RT is about determinism. You need to ensure that task will be able to</div>
respond in fixed time. If you allow arbitrary, unknown in advance,<br>
number of tasks share the same limited CPU share, you simply kill<br>
determinism.<br>
<br>
Personally I think that RT should be restricted to limited number of<br>
tasks that are known in advance; then it is responsibility of<br>
administrator to allocate their CPU share according to requirements.<br>
<div class="im"><br>
&gt;<br>
&gt; 2011/2/14 Lennart Poettering &lt;<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
</div><div class="im">&gt;&gt; I am not aware of any typical daemon we ship that would use RT<br>
&gt;&gt; scheduling hence we are keeping the default &#39;cpu&#39; cgroup sorting for<br>
&gt;&gt; system daemons enabled. However user applications are more likely to use<br>
&gt;&gt; RT (for example PA does) and hence we have disabled this for sessions<br>
&gt;&gt; for now.<br>
&gt;&gt;<br>
<br>
</div>and for reasons outlined above I think that either PA should not<br>
require RT to run, or we need dedicated system wide PA daemon that can<br>
be made RT :)<br>
</blockquote></div>Agree in this sense. RT can be seen as &#39;hardcode&#39; some computing resource to simulate dedicated hardware, in other words, virtual dsp, should reside at system scope.<br><br clear="all"><br><div>
<br></div><div><br>-- <br>Regards,<div><br><div>- cee1</div></div><br>
</div>