Date: Thu, 19 May 2016 14:43:31 -0700 From: Alfred Perlstein <bright@mu.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: geom@freebsd.org, arch@freebsd.org Subject: Re: Removing Giant asserts from geom Message-ID: <b7900e38-0d2c-e0e6-d2b5-4105b2bc278c@mu.org> 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 5/19/16 2: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. > Thank you Konstantin, makes sense. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b7900e38-0d2c-e0e6-d2b5-4105b2bc278c>