28 Feb
2011
28 Feb
'11
7:11 p.m.
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:
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.
On Mon, 2011-02-28 at 18:53 +0100, torbenh wrote:
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.
On Tue, Feb 22, 2011 at 03:47:53PM +0100, Mike Galbraith wrote:
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. 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. 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.
-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