Date: Fri, 11 Feb 2005 09:14:22 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Matt Mackall <mpm@selenic.com>
Cc: Chris Wright <chrisw@osdl.org>, "Jack O'Quin" <jack.oquin@gmail.com>,
       Andrew Morton <akpm@osdl.org>, Christoph Hellwig <hch@infradead.org>,
       linux-kernel@vger.kernel.org, Paul Davis <paul@linuxaudiosystems.com>,
       Con Kolivas <kernel@kolivas.org>, rlrevell@joe-job.com
Subject: Re: 2.6.11-rc3-mm2
Message-ID: <20050211081422.GB2287@elte.hu>
References: <a075431a050210125145d51e8c@mail.gmail.com> <20050211000425.GC2474@waste.org> <20050210164727.M24171@build.pdx.osdl.net> <20050211020956.GC15058@waste.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050211020956.GC15058@waste.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3663
Lines: 75


* Matt Mackall <mpm@selenic.com> wrote:

> > > What happened to the RT rlimit code from Chris?
> > 
> > I still have it, but I had the impression Ingo didn't like it as a long
> > term solution/hack (albeit small) to the scheduler.  Whereas the rt-lsm
> > patch is wholly self-contained.
> 
> I think it's important to recognize that we're trying to address an
> issue that has a much wider potential audience than pro audio users,
> and not very far off - what is high end audio performance today will
> be expected desktop performance next year.

i disagree that desktop performance tomorrow will necessarily have to
utilize SCHED_FIFO. Today's desktop audio applications perform quite
good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
interactivity/latency fixes such as PREEMPT_BKL].

I agree (and hope) that tomorrow's "stock" desktop will be based on
today's pro audio architectures, but tomorrows CPUs will be much faster
and tomorrows desktop apps dont want to spend 30%+ CPU time on creating
audio.

the pro applications will always want to have a 100% guarantee (it
really sucks to generate a nasty audio click during a live performance)
and want to utilize as much CPU time for audio as needed. They are also
clearly the most complex creators of audio so they go far above the
normal (and reasonable) CPU-use/latency expectations and tradeoffs of
the stock scheduler.

> So I think it's critical that we find solution that's appropriate for
> _every single box_, because realistically vendors are going to ship
> with this "wholly self-contained" feature turned on by default next
> year, at which point the "containment" will be nil and whatever warts
> it has will be with us forever.

an "RT priorities rlimit" is still not adequate as a desktop solution,
because it still allows the box to be locked up. Also, if it turns out
to be a mistake then it's already codified into the ABI, while RT-LSM is
much less 'persistent' and could be replaced much easier. RT-LSM is also
more flexible and more practical. (an rlimit needs changes across a
number of userspace components, delaying its adoptation.)

> The rlimit stuff is not perfect, but it's a much better fit for the
> UNIX model generally, which is a fairly big win. [...]

a 'locked up box' is as far away from the UNIX model as it gets.

perhaps, if the need arises, we can add the RT-throttling sysctl (which
still wont give RT priorities to unprivileged users and would serve as a
way to throttle privileged RT tasks), which could thus make the RT-LSM
solution pretty safe. Right now Jack has its own watchdog thread which
should solve most of the lockup situations.  Lets not overdesign the
solution, especially when we dont yet know how the problem really looks
like.

or an even simpler solution for the lockup problem would be a
kernel-based RT watchdog. In fact 2.6.11-rc3-mm2 already includes such a
watchdog (written by yours truly):

 http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm2/broken-out/detect-soft-lockups.patch

right now softlockup-detect runs at SCHED_FIFO prio 99 and only prints a
warning - but it could easily run at SCHED_FIFO prio 1 [to detect
lockups generated by all RT tasks] and it could actively try to renice
(or kill) tasks that run for too long. So very likely there will be an
easy upstream mechanism for any problem that could arise out of RT-LSM.

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