From owner-freebsd-arch@freebsd.org Thu May 19 21:35:36 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B7CB41EEF for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 16FC11A18 for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 12DA4B41EED; Thu, 19 May 2016 21:35:36 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 128EFB41EEC for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D15FB1A16 for ; Thu, 19 May 2016 21:35:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id 190so124559549iow.1 for ; Thu, 19 May 2016 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=56NIbtNbLlzDvThqDkhfRCWD+zx79zvQY9sMgH1gmTI=; b=ZhiS6hp5LKRKzgyLEg3G+yuyqXIvPpn9V/u0LWFGslG4LDefGmfvZDY5hk3CqYAIKn faoo8SkMFjGQsjwCn6Hmgd42T4Z4W+QxPXey8eiVOWv+rf3QcKljEl7uhV+n4u0G7ZPJ GPz8W0J1iZhQJoJJAIwoY0hKeW9taPj/E0Gd5lWcYS6jvLo81Fzi5y29+m6pU82VNXIr ejvI7/wAMNjt/NZcx9I2a8KZK5VAy+0gOFJU6GvNrSp0AHMndMktuPAyRD75GzvRgQm3 jYhPXgKaIdltE/FH7PlWWF29UjQxJVf7O9McOoumaRl8Hc2jlG/QvWJFoxscBgAvkK7/ NKew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=56NIbtNbLlzDvThqDkhfRCWD+zx79zvQY9sMgH1gmTI=; b=btlTVe+EStemANWEIFcOKh/9F3a39nvM++Bgpt1xFsSSf7wGUIuP6YjC0ThlfiGFcD 8I1zH29wk+JWPQdcRemojuBPEyYT/V+WspOTiVAry9zTDYYR2s1FEQ+udgMFssNq2po7 bic6HbkEouyNfz0xI6NzPL3vKJWiVdsklVrJNwWoYQsTKrJ7yTCZRprYpoq/qMD1Iinv t3cmDIIXBdwcwu8EiCVVmeANB7AiW6NljSh/mdiH1rE+iwE9f59hBWQHGX1GVD15PHqH XDXMN4A49mahxKl3aMtwlxnbIFus//udXD/qTKkrfvCPCbyPIaeG0CMw2JRIMlhTpNuO jbRA== X-Gm-Message-State: AOPr4FVgQoMyikOsvkFsy419fofLbK3MOep5Ytjy+crS2kRHXzFZWIk+ft7tP7cGIOQYzGuryzdQoKWryK70Wg== MIME-Version: 1.0 X-Received: by 10.36.70.7 with SMTP id j7mr4806886itb.72.1463693735230; Thu, 19 May 2016 14:35:35 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.79.75.68 with HTTP; Thu, 19 May 2016 14:35:35 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160519213128.GT89104@kib.kiev.ua> References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> <20160519213128.GT89104@kib.kiev.ua> Date: Thu, 19 May 2016 15:35:35 -0600 X-Google-Sender-Auth: O3xZTgY3zSYoqJ9xkwhh0htQZ7U Message-ID: Subject: Re: Removing Giant asserts from geom From: Warner Losh To: Konstantin Belousov Cc: Alfred Perlstein , geom@freebsd.org, "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2016 21:35:36 -0000 On Thu, May 19, 2016 at 3:31 PM, Konstantin Belousov wrote: > On Thu, May 19, 2016 at 01:57:53PM -0700, Alfred Perlstein wrote: >> OK, and why is thread0 needing Giant for so long? > [Below is my opinion] > > It does not need Giant per se, it needs a work done to audit and turn it > off. Probably most high profile subsystem in the kernel still relying on > Giant is the newbus. Easy to see consequence is that handling thread0, > that spends most of the time in discovering and configuring devices, > actually needs to provide proper locking for the newbus. > > At least one attempt to do the later failed. Troubles are both in the > strange recursiveness of newbus, where device method could call into > subr_bus.c, and in potential offloading of some work to other thread, > which means that naive surround of the subr_bus.c methods with some > global sleepable (and even recursive) lock would not work. > > Since newbus activity and early startup are rare events, fine-grained > locking for them would result in, well, fine grained locking. There > would be no break-through performance improvements after really hard > work, including handling user reports for long time. > > So, it is not a priority for most people. I know of three runs at the newbus locking issue that have failed. It's not easy or trivial because it calls into so many different subsystems, many in odd ways that aren't done elsewhere. Warner