From owner-freebsd-current@FreeBSD.ORG Fri Jul 31 17:19:32 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0331065676 for ; Fri, 31 Jul 2009 17:19:32 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe01.swip.net [212.247.154.1]) by mx1.freebsd.org (Postfix) with ESMTP id BA1208FC2A for ; Fri, 31 Jul 2009 17:19:31 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=8kQB0OdkAAAA:8 a=mmHwNsfE3PVCs0CkINQA:9 a=fS0clcq0GpnDBqjpB7IVlC5K2CwA:4 a=9aOQ2cSd83gA:10 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop.adsl.tele2.no) by mailfe01.swip.net (CommuniGate Pro SMTP 5.2.13) with ESMTPA id 233837621; Fri, 31 Jul 2009 19:19:30 +0200 From: Hans Petter Selasky To: freebsd-current@freebsd.org Date: Fri, 31 Jul 2009 19:19:25 +0200 User-Agent: KMail/1.11.4 (FreeBSD/8.0-BETA2; KDE/4.2.4; i386; ; ) References: <3bbf2fe10907310759o3be1f565t4122fcd66c4531f4@mail.gmail.com> <200907311818.08481.hselasky@c2i.net> <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com> In-Reply-To: <3bbf2fe10907310934r640350c6n7ea89d3aaf36a05f@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200907311919.26913.hselasky@c2i.net> Cc: Attilio Rao , Peter Holm Subject: Re: [PATCH] Newbus locking X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2009 17:19:32 -0000 On Friday 31 July 2009 18:34:26 Attilio Rao wrote: > 2009/7/31 Hans Petter Selasky : > > Hi, > > > > Speaking about the USB subsystem and newbus: > > Hans, > I wanted to maintain this private to us but you clearly don't > understand what races live in newbus, what requirements in locking we > need to protect that and also how a sane locking scheme should be > built. > Please drop this conversation. Hi, I'm not saying that your approach will not work or that it is wrong. I'm saying that it is not fast enough. Your patch affects the boottime, in a negative way. Sure I can help you eliminate blocking the whole USB explore thread from newbus_lock(), but there are sometimes also synchronous delay inside device probe functions, and I think for those cases it would be better if we kept using Giant, because then all sleep calls have drop- and pickup- Giant code, but there is no automatic drop and pickup for the newbus_lock()! How can we multi-thread the boot-sequence given your newbus_lock() requirement ? --HPS