Messages in this thread | | | Date | 30 May 2005 14:40:38 +0200 | Date | Mon, 30 May 2005 14:40:38 +0200 | From | Andi Kleen <> | Subject | Re: what is the -RT tree |
| |
On Mon, May 30, 2005 at 02:10:31PM +0200, Ingo Molnar wrote: > > * Andi Kleen <ak@muc.de> wrote: > > > > > > Yes, as Ingo stated many times, addition cond_resched() to > > > > > might_sleep() does achieve the "usable" latencies -- and > > > > > obviously that's hacky. > > > > > > > > But it's the only way to get practial(1) low latency benefit to > > > > everybody [...] > > > > (1) = not necessarily provable, but good enough at least for jack > > > > et.al. > > > > > > FYI, to get good latencies for jack you currently need the -RT tree and > > > CONFIG_PREEMPT. (see Lee Revell's and Rui Nuno Capela's extensive tests) > > > > Yeah, but you did a lot of (often unrelated to rt preempt) latency > > fixes in RT that are not yet merged into mainline. When they are all > > merged things might be very different. And then there can be probably > > more fixes. > > your argument above == cond_resched() in might_sleep() [ == VP ] is the > only way to get practical (e.g. jack) latencies.
My argument was basically that we have no other choice than to fix it anyways, since the standard kernel has to be usable in this regard.
(it is similar to that we e.g. don't do separate "server VM" and "desktop VM"s although it would be sometimes tempting. after all one wants a kernel that works well on a variety of workloads and doesn't need to extensive hand tuning)
> > my argument == i do agree that -VP is a step forward from PREEMPT_NONE > (i'd not have written and released it otherwise), but is > by no means enough for jack. You need at least the -RT > tree + CONFIG_PREEMPT to achieve good jack latencies.
Ok where are the big issues left?
Stuff where old-style preempt helps (= not scheduling during long code without single big lock) can be usually fixed without too much effort with cond_resched()s. Don't you agree on that?
Your argument of it being more ongoing work to fix latencies again is a good one, but again I see no alternative to it since the standard well-performing kernel cannot be "abandoned" in this regard.
> perhaps there's some misunderstanding wrt. what the -RT tree is. The -RT > tree is a collection of latency related patches and features: it > introduces the VP and PREEMPT_RT features, and it also improves all > preemption models (including CONFIG_PREEMPT). Furthermore, it includes > (in-kernel) features to measure and debug latencies. It's called -RT > because PREEMPT_RT is undoubtedly the 'crown jewel' feature, but that > does not mean it's the only goal of the patchset.
Yes, I understand that. But because of that it is not really fair to compare the standard kernel to RT tree with all bells and whistles enabled. I think it would be much better if RT was considered as individual pieces, not all or nothing.
-Andi - 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/
| |