Re: [LAU] [patch] Re: autogroup: sched_setscheduler() fails - Linux-audio-user

28 Feb 2011

sorry... i cced the old ML addresses :S
fixing the CC now.

On Mon, Feb 28, 2011 at 07:29:54PM +0100, Mike Galbraith wrote:
...
  On Mon, 2011-02-28 at 18:53 +0100, torbenh wrote:

 On Tue, Feb 22, 2011 at 03:47:53PM +0100, Mike Galbraith wrote:
  On Tue, 2011-02-22 at 13:24 +0100, torbenh
wrote:
 > On Fri, Feb 18, 2011 at 01:50:12PM +0100, Mike Galbraith wrote:   
   >
Sounds like you just want to turn CONFIG_RT_GROUP_SCHED off.

 but distros turn it on.
 we could prevent debian from turning it on. 
 now opensuse 11.4 has turned it on.  
 If you or anyone else turns on RT_GROUP_SCHED, you will count your
 beans, and pay up front, or you will not play.  That's a very sensible
 policy for realtime.  
 this probably means that generic computer distros should not turn this
 option on ?  
 Yeah, agreed, not for a great default config, but only because
 newfangled automation thingies can't (possibly?) deal with it sanely. 
but this is excactly the reason, why i would advocate rt_runtime to be
in a separate cgroups system.
any admin who wants to limit RT runtime could still do it.
people who dont care, and just want their cfs slices configured, can
still do it.

...

   If
systemd deals with it at all, seems to me it can only make a mess of
 it.  But who knows, maybe they made a clever allocator.  If they didn't,
 they'll need an escape hatch methinks.  
 the problem is that audio applications can not really pre allocate their
 cpu needs. user can add processing plugins until he pushes his machine
 to the limit. (or the cgroup where his process is running in)

 we dont really have a mechanism for plugins to publish their needed
 cycles.  
 I can't see how it could matter what any individual group of arbitrary
 groups N (who can appear/disappear in the blink of an eye) advertises as
 it's wish of the instant.  "Hard" + "Arbitrary" doesn't
compute for me. 
i dont really understnad this statement.

...

 	-Mike

 --
 To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
 the body of a message to majordomo(a)vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/ 
-- 
torben Hohn