Date: Thu, 19 May 2016 15:35:35 -0600 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Alfred Perlstein <bright@mu.org>, geom@freebsd.org, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Removing Giant asserts from geom Message-ID: <CANCZdfrjh8AG_xLdKnpcA=k4n1gKo7rgmhBmSAMnov1erqXLYA@mail.gmail.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, May 19, 2016 at 3:31 PM, Konstantin Belousov <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrjh8AG_xLdKnpcA=k4n1gKo7rgmhBmSAMnov1erqXLYA>