From owner-freebsd-arch@FreeBSD.ORG Thu Mar 27 12:21:35 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CC6337B401; Thu, 27 Mar 2003 12:21:35 -0800 (PST) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id B522E43F93; Thu, 27 Mar 2003 12:21:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.8/8.12.6) with ESMTP id h2RKLY31049841; Thu, 27 Mar 2003 12:21:34 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.8/8.12.6/Submit) id h2RKLYo8049840; Thu, 27 Mar 2003 12:21:34 -0800 (PST) Date: Thu, 27 Mar 2003 12:21:34 -0800 (PST) From: Matthew Dillon Message-Id: <200303272021.h2RKLYo8049840@apollo.backplane.com> To: Nate Lawson References: X-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,REFERENCES version=2.50 X-Spam-Level: X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) cc: arch@freebsd.org cc: current@freebsd.org Subject: Re: 5.x locking plan X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2003 20:21:37 -0000 :My curiousity has overcome my fear of the bikeshed so I'll ask the :question that has been bugging me for a while. Why haven't we gone :through the tree and created a lock for each spl and then converted every :spl call into the appropriate mtx_lock call? At that point, we can mark :large sections of the tree giant-free and then make the locking data-based :(instead of code-based) one section at a time. This is the approach :Solaris took. : :-Nate The problem is that SPLs are per-thread masks, and different sets of bits can be added or removed from the master mask in any order and at any time. There is no direct translation to a mutex (which cannot be obtained in random order, is not per-thread, and may result in preemption or a context switch). Most of the code locked under Giant assumes the single-threading of kernel threads regardless of the SPL. This 'inherent' single threading is one the reasons why the original code was so efficient. Since preemption can occur now under many new circumstances, including when 'normal' (non-spin) mutexes are used to replace prior uses of SPLs (which could not cause thread level preemption)... well, it basically means there is no easy way to remove Giant short of going through every bit of code and fixing it one subsystem at a time. Giant itself is a special case. It is not a normal mutex. Instead, the kernel very carefully saves and restores the state of Giant on a per-thread basis so programs don't 'need to know' whether Giant is being held or not and so Giant can be held in combination with another mutex without violating the basic 'only one mutex can be held when going to sleep' rule. -Matt Matthew Dillon