Hi Lennart,<div><br><div class="gmail_quote">2010/12/24 Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> This is related to the issue reported in LWN about JACK+cgroups. Also,<br> this issue breaks my 4 line bash patch as known from slashdot,</blockquote><div>AIUI, This is not a kernel problem, and is related with <a href="http://sourceforge.net/projects/libcg/">libcgroup</a>.</div><div> <br></div><div>Quotes from LWN(<a href="http://lwn.net/Articles/420407" target="_blank">lwn.net/Articles/420407</a>):</div><div>"""</div><div><div>if a process is run in a control group with no access to realtime scheduling, that process will not be able to put itself into a realtime scheduling class regardless of any resource limit settings.</div> <div><br></div><div>The kernel, by default, grants realtime access to the "root" control group - the one which contains all processes in the absence of some policy to the contrary. </div></div><div>"""</div> <div><br></div><div>"""</div><div><div>If, however, (1) the libcgroup package has been installed, and (2) that package has been configured to put all user processes into a default (non-root) group, the situation changes.</div> <div><br></div><div>The libcgroup default group does not have realtime access, so processes expecting to be able to run in a realtime scheduling class will be disappointed.</div></div><div>"""</div><div><br> </div><div>IMHO, It should be the job of some thing(like systemd) directly play with cgroup.</div><div>It seems systemd doesn't use libcgroup, am I right? Then, It should be fine if systemd grants realtime access to cgroup for each user session itself.</div> <div><br></div></div></div> <br clear="all"><br><div><br>-- <br>Regards,<div><br><div>- cee1</div></div><br> </div>