On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> >
> > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> >
> > Signed-off-by: Mike Galbraith <[email protected]>
> > Reported-by: Bharata B Rao <[email protected]>
>
> Thanks, applied!
while this behaviour is certeinly necessary, i think this is a hack.
it fixes the problem for autogroups.
But its not fixed for things which want to control the cfs shares via
normal cgroups.
why isnt rt_runtime_us residing in a separate (new) subsystem ?
--
torben Hohn
On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > >
> > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > >
> > > Signed-off-by: Mike Galbraith <[email protected]>
> > > Reported-by: Bharata B Rao <[email protected]>
> >
> > Thanks, applied!
>
> while this behaviour is certeinly necessary, i think this is a hack.
> it fixes the problem for autogroups.
> But its not fixed for things which want to control the cfs shares via
> normal cgroups.
You mean automated control ala systemd? For a static set of groups, it
works fine. I was wondering how systemd would deal with it.
> why isnt rt_runtime_us residing in a separate (new) subsystem ?
The allocation problem was shamelessly punted back to the user, where I
think it truly belongs.
-Mike
On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > >
> > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > >
> > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > Reported-by: Bharata B Rao <[email protected]>
> > >
> > > Thanks, applied!
> >
> > while this behaviour is certeinly necessary, i think this is a hack.
> > it fixes the problem for autogroups.
> > But its not fixed for things which want to control the cfs shares via
> > normal cgroups.
>
> You mean automated control ala systemd? For a static set of groups, it
> works fine. I was wondering how systemd would deal with it.
but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
off. iE N cgroups with different cpu.share values, but each with
rt_runtime_us=950000
if the rt_runtime_us was in a different subsystem, its my understanding
that i could leave rt_runtime_us alone, and have all tasks in the root
group in the rt_runtime subsystem.
>
> > why isnt rt_runtime_us residing in a separate (new) subsystem ?
>
> The allocation problem was shamelessly punted back to the user, where I
> think it truly belongs.
sure it belongs to the user. but what if user wants to have different
cpu.shares, but full rt_runtime_us for all tasks ?
i can not have 2 sibling cgroups, whose rt_runtime_us adds up to over
the rt_period ...
>
> -Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
torben Hohn
On Fri, 2011-02-18 at 12:09 +0100, torbenh wrote:
> On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> > On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > > >
> > > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > > >
> > > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > > Reported-by: Bharata B Rao <[email protected]>
> > > >
> > > > Thanks, applied!
> > >
> > > while this behaviour is certeinly necessary, i think this is a hack.
> > > it fixes the problem for autogroups.
> > > But its not fixed for things which want to control the cfs shares via
> > > normal cgroups.
> >
> > You mean automated control ala systemd? For a static set of groups, it
> > works fine. I was wondering how systemd would deal with it.
>
> but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
> off. iE N cgroups with different cpu.share values, but each with
> rt_runtime_us=950000
? if CONFIG_RT_GROUP_SCHED was a noop, it wouldn't exist.
> if the rt_runtime_us was in a different subsystem, its my understanding
> that i could leave rt_runtime_us alone, and have all tasks in the root
> group in the rt_runtime subsystem.
Sounds like you just want to turn CONFIG_RT_GROUP_SCHED off.
> > The allocation problem was shamelessly punted back to the user, where I
> > think it truly belongs.
>
> sure it belongs to the user. but what if user wants to have different
> cpu.shares, but full rt_runtime_us for all tasks ?
Then the user doesn't want CONFIG_RT_GROUP_SCHED set.
-Mike
On Fri, Feb 18, 2011 at 01:50:12PM +0100, Mike Galbraith wrote:
> On Fri, 2011-02-18 at 12:09 +0100, torbenh wrote:
> > On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> > > On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > > > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > > > >
> > > > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > > > >
> > > > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > > > Reported-by: Bharata B Rao <[email protected]>
> > > > >
> > > > > Thanks, applied!
> > > >
> > > > while this behaviour is certeinly necessary, i think this is a hack.
> > > > it fixes the problem for autogroups.
> > > > But its not fixed for things which want to control the cfs shares via
> > > > normal cgroups.
> > >
> > > You mean automated control ala systemd? For a static set of groups, it
> > > works fine. I was wondering how systemd would deal with it.
> >
> > but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
> > off. iE N cgroups with different cpu.share values, but each with
> > rt_runtime_us=950000
>
> ? if CONFIG_RT_GROUP_SCHED was a noop, it wouldn't exist.
>
> > if the rt_runtime_us was in a different subsystem, its my understanding
> > that i could leave rt_runtime_us alone, and have all tasks in the root
> > group in the rt_runtime subsystem.
>
> Sounds like you just want to turn CONFIG_RT_GROUP_SCHED off.
>
> > > The allocation problem was shamelessly punted back to the user, where I
> > > think it truly belongs.
> >
> > sure it belongs to the user. but what if user wants to have different
> > cpu.shares, but full rt_runtime_us for all tasks ?
>
> Then the user doesn't want CONFIG_RT_GROUP_SCHED set.
many users dont configure their kernels themselves.
and this setting is not dynamic.
i guess its highly unlikely any normal user wants CONFIG_RT_GROUP_SCHED.
but maybe distros will turn it on.
--
torben Hohn
On Fri, Feb 18, 2011 at 01:50:12PM +0100, Mike Galbraith wrote:
> On Fri, 2011-02-18 at 12:09 +0100, torbenh wrote:
> > On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> > > On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > > > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > > > >
> > > > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > > > >
> > > > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > > > Reported-by: Bharata B Rao <[email protected]>
> > > > >
> > > > > Thanks, applied!
> > > >
> > > > while this behaviour is certeinly necessary, i think this is a hack.
> > > > it fixes the problem for autogroups.
> > > > But its not fixed for things which want to control the cfs shares via
> > > > normal cgroups.
> > >
> > > You mean automated control ala systemd? For a static set of groups, it
> > > works fine. I was wondering how systemd would deal with it.
> >
> > but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
> > off. iE N cgroups with different cpu.share values, but each with
> > rt_runtime_us=950000
>
> ? if CONFIG_RT_GROUP_SCHED was a noop, it wouldn't exist.
>
> > if the rt_runtime_us was in a different subsystem, its my understanding
> > that i could leave rt_runtime_us alone, and have all tasks in the root
> > group in the rt_runtime subsystem.
>
> 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.
>
> > > The allocation problem was shamelessly punted back to the user, where I
> > > think it truly belongs.
> >
> > sure it belongs to the user. but what if user wants to have different
> > cpu.shares, but full rt_runtime_us for all tasks ?
>
> Then the user doesn't want CONFIG_RT_GROUP_SCHED set.
but distros force it onto the user.
if systemd shows up, and puts things into different cgroups,
we end up with a pretty fragmented rt_runtime_us.
>
> -Mike
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
torben Hohn
On Tue, 2011-02-22 at 13:24 +0100, torbenh wrote:
> On Fri, Feb 18, 2011 at 01:50:12PM +0100, Mike Galbraith wrote:
> > On Fri, 2011-02-18 at 12:09 +0100, torbenh wrote:
> > > On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> > > > On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > > > > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > > > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > > > > >
> > > > > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > > > > >
> > > > > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > > > > Reported-by: Bharata B Rao <[email protected]>
> > > > > >
> > > > > > Thanks, applied!
> > > > >
> > > > > while this behaviour is certeinly necessary, i think this is a hack.
> > > > > it fixes the problem for autogroups.
> > > > > But its not fixed for things which want to control the cfs shares via
> > > > > normal cgroups.
> > > >
> > > > You mean automated control ala systemd? For a static set of groups, it
> > > > works fine. I was wondering how systemd would deal with it.
> > >
> > > but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
> > > off. iE N cgroups with different cpu.share values, but each with
> > > rt_runtime_us=950000
> >
> > ? if CONFIG_RT_GROUP_SCHED was a noop, it wouldn't exist.
> >
> > > if the rt_runtime_us was in a different subsystem, its my understanding
> > > that i could leave rt_runtime_us alone, and have all tasks in the root
> > > group in the rt_runtime subsystem.
> >
> > 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.
> > > > The allocation problem was shamelessly punted back to the user, where I
> > > > think it truly belongs.
> > >
> > > sure it belongs to the user. but what if user wants to have different
> > > cpu.shares, but full rt_runtime_us for all tasks ?
> >
> > Then the user doesn't want CONFIG_RT_GROUP_SCHED set.
>
> but distros force it onto the user.
> if systemd shows up, and puts things into different cgroups,
> we end up with a pretty fragmented rt_runtime_us.
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.
-Mike
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:
> > > On Fri, 2011-02-18 at 12:09 +0100, torbenh wrote:
> > > > On Tue, Feb 15, 2011 at 05:43:30PM +0100, Mike Galbraith wrote:
> > > > > On Tue, 2011-02-15 at 16:46 +0100, torbenh wrote:
> > > > > > On Mon, Jan 17, 2011 at 02:16:00PM +0100, Peter Zijlstra wrote:
> > > > > > > On Thu, 2011-01-13 at 04:54 +0100, Mike Galbraith wrote:
> > > > > > > > sched, autogroup: fix CONFIG_RT_GROUP_SCHED sched_setscheduler() failure.
> > > > > > > >
> > > > > > > > If CONFIG_RT_GROUP_SCHED is set, __sched_setscheduler() fails due to autogroup
> > > > > > > > not allocating rt_runtime. Free unused/unusable rt_se and rt_rq, redirect RT
> > > > > > > > tasks to the root task group, and tell __sched_setscheduler() that it's ok.
> > > > > > > >
> > > > > > > > Signed-off-by: Mike Galbraith <[email protected]>
> > > > > > > > Reported-by: Bharata B Rao <[email protected]>
> > > > > > >
> > > > > > > Thanks, applied!
> > > > > >
> > > > > > while this behaviour is certeinly necessary, i think this is a hack.
> > > > > > it fixes the problem for autogroups.
> > > > > > But its not fixed for things which want to control the cfs shares via
> > > > > > normal cgroups.
> > > > >
> > > > > You mean automated control ala systemd? For a static set of groups, it
> > > > > works fine. I was wondering how systemd would deal with it.
> > > >
> > > > but i can not get the same behaviour as if CONFIG_RT_GROUP_SCHED was
> > > > off. iE N cgroups with different cpu.share values, but each with
> > > > rt_runtime_us=950000
> > >
> > > ? if CONFIG_RT_GROUP_SCHED was a noop, it wouldn't exist.
> > >
> > > > if the rt_runtime_us was in a different subsystem, its my understanding
> > > > that i could leave rt_runtime_us alone, and have all tasks in the root
> > > > group in the rt_runtime subsystem.
> > >
> > > 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 ?
>
> > > > > The allocation problem was shamelessly punted back to the user, where I
> > > > > think it truly belongs.
> > > >
> > > > sure it belongs to the user. but what if user wants to have different
> > > > cpu.shares, but full rt_runtime_us for all tasks ?
> > >
> > > Then the user doesn't want CONFIG_RT_GROUP_SCHED set.
> >
> > but distros force it onto the user.
> > if systemd shows up, and puts things into different cgroups,
> > we end up with a pretty fragmented rt_runtime_us.
>
> 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.
--
torben Hohn
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.
> > 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.
-Mike
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
torben Hohn
On Mon, 2011-02-28 at 20:10 +0100, torbenh wrote:
> i dont really understnad this statement.
Doesn't matter, we're thinking about different subjects. You're
thinking of an unborn mechanism, I'm thinking of the living one.
-Mike
P.S. Kindly do not CC closed lists. Closed list readers only see your
part of any conversation, and anyone replying to you is rewarded with
bounce spam for their trouble.
On Tue, Mar 01, 2011 at 05:21:30AM +0100, Mike Galbraith wrote:
> P.S. Kindly do not CC closed lists. Closed list readers only see your
> part of any conversation, and anyone replying to you is rewarded with
> bounce spam for their trouble.
yeah. sorry. i thought the lists were open.
there doesnt seem to be interest in it anyways.
i guess i rest my case, and wait for things to fall apart.
--
torben Hohn