From owner-p4-projects@FreeBSD.ORG Fri Jun 9 22:43:45 2006 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id A120B16A46F; Fri, 9 Jun 2006 22:43:45 +0000 (UTC) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 775EA16A418; Fri, 9 Jun 2006 22:43:45 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id C11DA43D77; Fri, 9 Jun 2006 22:43:44 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k59MhNp3041113; Fri, 9 Jun 2006 16:43:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4489F985.30502@samsco.org> Date: Fri, 09 Jun 2006 16:43:17 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: rookie@gufi.org References: <200605301926.k4UJQkgt055284@repoman.freebsd.org> <200605311657.44921.jhb@freebsd.org> <200606021022.44509.jhb@freebsd.org> <3bbf2fe10606020733j12bf706em51408b384135e966@mail.gmail.com> In-Reply-To: <3bbf2fe10606020733j12bf706em51408b384135e966@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on pooker.samsco.org Cc: "M. Warner Losh" , perforce@freebsd.org, kmacy@freebsd.org, John Baldwin , Hans Petter Selasky Subject: Re: PERFORCE change 98153 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jun 2006 22:43:45 -0000 Attilio Rao wrote: > 2006/6/2, John Baldwin : > >> On Thursday 01 June 2006 20:26, Kip Macy wrote: >> > > I'd rather avoid this for now as it will have to be backed out for >> interrupt >> > > filters. >> > >> > I don't know anything about interrupt filters, so please let me know >> > what you have in mind. The whole of interrupt handling is far too >> > heavyweight at the moment. >> >> With interrupt filters you can have both an INTR_FAST style handler and a >> threaded handler, and the INTR_FAST style handler will have a return >> value to >> determine if it's associated ithread should be scheduled and to let the >> calling code know if it has handled the interrupt so that it doesn't >> need to >> be masked, or if the interrupt wasn't for this device at all. > > > I was wondering, it would not be better writing a complete ithread > mechanism (including lazy scheduling/context stealing) instead using > ifilters? I don't know if this is fair, but, commonly, ithread seems > having better performance than ifilters (when correclty managed). > > Attilio > > I demonstrated pretty clearly with if_em that filters beat ithreads by a large margin. Whether or not there is context stealing and all of that magic, there is still the problem of latency caused by multiple interrupt sources sharing the same ithread. If two high speed, high priority devices are sharing the same interrupt vector and thus the same ithread, one will always have to wait for the other to block on locks and do PCI accesses. All other arguments aside, that is the fatal flaw. MSI might help, it will be a long time until legacy interrupt delivery schemes are gone from the PC platform. Heck, we still have to take ISA interrupt delivery into account, and ISA has been dead for more than 10 years! As for context stealing, it's been tried several times in FreeBSD, and has never been found to have a benefit. It's an attractive concept, but implementing it seems to run into hidden costs and problems. If someone can produce a working prototype the demonstrates a benefit, then that's great. But until then, we can't keep on designing our system around features that don't exist. Scott