Removing Giant asserts from geom

Warner Losh imp at bsdimp.com
Thu May 19 21:35:36 UTC 2016


On Thu, May 19, 2016 at 3:31 PM, Konstantin Belousov
<kostikbel at 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


More information about the freebsd-geom mailing list