From owner-freebsd-smp@FreeBSD.ORG Thu Apr 24 11:21:15 2003 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5DD537B401 for ; Thu, 24 Apr 2003 11:21:15 -0700 (PDT) Received: from mail.speakeasy.net (mail16.speakeasy.net [216.254.0.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1838E43FBD for ; Thu, 24 Apr 2003 11:21:15 -0700 (PDT) (envelope-from jhb@FreeBSD.org) Received: (qmail 23633 invoked from network); 24 Apr 2003 18:21:21 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender )encrypted SMTP for ; 24 Apr 2003 18:21:21 -0000 Received: from laptop.baldwin.cx (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.8/8.12.8) with ESMTP id h3OILBOv000740; Thu, 24 Apr 2003 14:21:11 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.4 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <3EA72A0B.5000606@cs.rutgers.edu> Date: Thu, 24 Apr 2003 14:21:14 -0400 (EDT) From: John Baldwin To: Aniruddha Bohra cc: freebsd-smp@freebsd.org Subject: Re: Question about interrupt threads X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Apr 2003 18:21:16 -0000 On 24-Apr-2003 Aniruddha Bohra wrote: > Hello > Thanks for your answer. I have some questions though > >>> My question is after all subsystems that lock giant are made >>>INTR_MPSAFE will the implementation go back to non-process >>>context interrupt handling (as in older versions) ? >>> >>> >> >>I would like that, but don't see how it could work right. >> >> > Provided all ISRs spin on their locks, and do not sleep, we can assume the > critical section to be small enough as to not allow interrupt handlers > on other CPUs > to spin for a long time. Then, the problem does go away. Or am I missing > something important here ? Understandably while there is a GIANT lock > protecting ISRs, this is not possible. Our default mutex locks are not spin-only. Instead, when a thread contends for a lock, it is suspended. It's priority is propagated to the holder of the lock, and the thread will resume when the lock is released. In order to not suspend the thread that got interrupted, we give each interrupt source it's own thread context to execute its handlers in. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/