Date: Fri, 20 May 2016 00:31:28 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Alfred Perlstein <bright@mu.org> Cc: geom@freebsd.org, arch@freebsd.org Subject: Re: Removing Giant asserts from geom Message-ID: <20160519213128.GT89104@kib.kiev.ua> In-Reply-To: <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org> References: <20160519105634.GO89104@kib.kiev.ua> <573DEA73.4080408@mu.org> <20160519191247.GQ89104@kib.kiev.ua> <53397f3f-1056-ceb7-ce3a-5269ac1d29e2@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160519213128.GT89104>