From owner-freebsd-geom@freebsd.org Thu May 19 21:35:36 2016 Return-Path: Delivered-To: freebsd-geom@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 28781B41EEE for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0910C1A17 for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 04847B41EEB; Thu, 19 May 2016 21:35:36 +0000 (UTC) Delivered-To: geom@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 042E7B41EEA for ; Thu, 19 May 2016 21:35:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 C28231A15 for ; Thu, 19 May 2016 21:35:35 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id p64so33144552ioi.2 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=lNSpdSgk5+rQ+TMaW18y22LPQT0SWX6EmHNqIEAGbtovMb1fbxAXJCW5qi7OyN6cyv y1pAufuRS8kxMb/J0WetJOrXp6HrVVPOggiCKxowqErCICsnrKX9aJInmnXKQGouzOVB E/u80dijYA7ZfST6P1vBhsJovWGMFWgXXSxtPUCRiun/6H6xDxl84trijdzXkHv5b/f5 tq98yQE4jRhPN38DbO713uSpI9o+yKfcQyR1bWKNnLyjxS2gVG3aRexchGm7wTNQv+aB yCtyVqRgkvsQNpyZBIcY6AqlJVohME0SCdQ9trPDmFEErT3uCcVps3hUGGtHTGIHuVQl 6Vig== X-Gm-Message-State: AOPr4FWGRR28LfstWUexmAcrh30AiqMnrZVUZ9a4kgI6u49buFF1pFdQcjOILUBt4s2UKhTBWIttmq/ODqtkqA== 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-geom@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: GEOM-specific discussions and implementations 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