Date: Fri, 27 May 2005 15:44:10 +0200
From: Ingo Molnar <mingo@elte.hu>
To: Andi Kleen <ak@muc.de>
Cc: Sven-Thorsten Dietrich <sdietrich@mvista.com>, dwalker@mvista.com,
       bhuey@lnxw.com, nickpiggin@yahoo.com.au, hch@infradead.org,
       akpm@osdl.org, linux-kernel@vger.kernel.org
Subject: Re: RT patch acceptance
Message-ID: <20050527134410.GA16158@elte.hu>
References: <20050525063306.GC5164@elte.hu> <m1br6zxm1b.fsf@muc.de> <1117044019.5840.32.camel@sdietrich-xp.vilm.net> <20050526193230.GY86087@muc.de> <20050526200424.GA27162@elte.hu> <20050527123529.GD86087@muc.de> <20050527124837.GA7253@elte.hu> <20050527125630.GE86087@muc.de> <20050527131317.GA11071@elte.hu> <20050527133122.GF86087@muc.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050527133122.GF86087@muc.de>
User-Agent: Mutt/1.4.2.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1446
Lines: 29


* Andi Kleen <ak@muc.de> wrote:

> > how would you do that, if even a first step (PREEMPT_VOLUNTARY) was 
> > opposed by some as possibly hurting throughput? I'm really curious, what 
> > would you do to improve PREEMPT_NONE's latencies?
> 
> Mostly in the classical way. Add cond_resched where needed. Break up a 
> few locks. Perhaps convert a few spinlocks that block preemption to 
> long and which are not taken that often to a new kind of 
> sleep/spinlock (TBD).  Then add more reschedule point again.

been there, done that. A couple of years ago i started out with a 
somewhat similar opinion to yours, which could be summed up as: "this 
cannot be that hard, just break up the code, damnit". Wrote tools to see 
where the latencies come from, and started sticking cond_resched()s in.  
A few years down the road and after multiple restarts (lowlatency patch, 
the first preempt prototype patch, -VP patchset, etc.) i ended up with 
the -RT patch and with two new preemption models (PREEMPT_VOLUNTARY and 
PREEMPT_RT) in addition to PREEMPT_NONE and PREEMPT. (With the extra 
twist that when i started then the kernel was only 2 million lines big, 
now it's 6+ million lines of code.)

	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/