From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261857AbUG1S22 (ORCPT ); Wed, 28 Jul 2004 14:28:28 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261875AbUG1S22 (ORCPT ); Wed, 28 Jul 2004 14:28:28 -0400 Received: from viper.oldcity.dca.net ([216.158.38.4]:43400 "HELO viper.oldcity.dca.net") by vger.kernel.org with SMTP id S261857AbUG1S20 (ORCPT ); Wed, 28 Jul 2004 14:28:26 -0400 Subject: Re: [patch] IRQ threads From: Lee Revell To: karim@opersys.com Cc: Scott Wood , Ingo Molnar , "La Monte H.P. Yarroll" , Manas Saksena , Philippe Gerum , linux-kernel In-Reply-To: <4107CA18.4060204@opersys.com> References: <20040727225040.GA4370@yoda.timesys> <4107CA18.4060204@opersys.com> Content-Type: text/plain Message-Id: <1091039327.747.26.camel@mindpipe> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 28 Jul 2004 14:28:47 -0400 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2004-07-28 at 11:45, Karim Yaghmour wrote: > Scott Wood wrote: > > I have attached a patch for implementing IRQ handlers in threads, for > > latency-reduction purposes. It requires that softirqs must be run in > > threads (or else they could end up running inside the IRQ threads, > > which will at the very least trigger bugs due to in_irq() being set). > > I've tested it with Ingo's voluntary-preempt J7 patch, and it should > > work with the TimeSys softirq thread patch as well (though you might > > get a conflict with the PF_IRQHANDLER definition; just merge them > > into one). > > My experience with clients who have been using TimeSys' stuff has been > abysmal. The fact of the of the matter is that most people who used > this were practically locked-in to TimeSys' services, unable to download > anything "standard" off the net and using it with their kernel. In one > example, we had to ditch the kernel the client got from TimeSys because > we had spent 10+ hours trying to get LTT to work on it without any > success whatsoever. > > As I had said on other lists before, I don't see the point of creating > that much complexity in the kernel in order to try to shave-off a little > bit more off of the kernel's interrupt response time. The fact of the > matter is that neither this patch nor most of the other patches suggested > makes the kernel truely hard-rt. These patches only make the kernel > respond "faster". If you really need hard-rt, then you should be using > the Adeos nanokernel. With Adeos, you can even get a hard-rt driver > without using RTAI or any of the other rt derivatives. > This is obvious FUD from someone who is selling something. Please keep this crap off LKML. Lee