[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1299588399.2308.1424.camel@twins>
Date: Tue, 08 Mar 2011 13:46:39 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Mike Galbraith <efault@....de>
Cc: Yong Zhang <yong.zhang0@...il.com>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: [patchlet] sched: fix rt throttle runtime borrowing
On Mon, 2011-03-07 at 15:27 +0100, Mike Galbraith wrote:
> sched: fix rt throttle runtime borrowing
>
> If allowed to borrow up to rt_period, the throttle has no effect on an out
> of control RT task, allowing it to consume 100% CPU indefinitely, blocking
> system critical SCHED_NORMAL threads indefinitely.
>
> To make the throttle a more effective safety mechanism, disable borrowing
> by default. while providing an opt-in switch for those who know the risks.
> Also fix the throttle such that it never silently bumps rt_runtime to the
> point that it disables itself (rt_runtime >= rt_period).
>
> Convert balance_runtime() and do_balance_runtime() to void since their
> return values are never used.
>
> Signed-off-by: Mike Galbraith <efault@....de>
I'm very hesitant here, pretty much all of the sched_rt cgroup stuff
needs to be thrown out and rewritten. Adding more knobs to it isn't
going to make things much better.
(I'd myself much prefer to simply not support SCHED_FIFO/RR at all, but
seeing as POSIX mandates that crap there's really no choice there).
Also, how much of a problem is it really? When I start a FIFO spinner on
my machine I can still ssh in and kill the thing.
Not allowing 100% FIFO usage on SMP is going to make it very very hard
to implement any kind of fifo-cgroup stuff.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists