Re: Killing Giant for 13

On Tue, Jul 13, 2021 at 9:13 AM Hans Petter Selasky <[email protected]> wrote:

> Hi,
>
> I've been pondering with some ideas around Giant removal too.
>
> First of all, I think the first step getting rid of Giant, is to move
> all Giant usage related to newbus into two own global functions, so we
> can start working on what and how the device tree should be protected
> separately. Personally I would prefer a sleepable EPOCH (See
> https://reviews.freebsd.org/D30376), because that would interact nicely
> with freeing the device softc and other internal structures.
>

Yea, I'm unsure of epoch or smr is the right path forward here, but at
a high level, I'm thinking along the same lines as you are.


> void
> device_tree_lock()
> {
>      mtx_lock(&Giant);
> }
>
> void
> device_tree_unlock()
> {
>      mtx_unlock(&Giant);
> }
>

I have a tree with this change worked through already, though with a
different name. I've also pushed Giant down a bit in a few places too
in that tree.


> Secondly I think that if we can remove all code sleeping with Giant, so
> to speak, either by using msleep(&Giant) or by using M_NOWAIT, we can
> get rid of the DROP and PICKUP Giant macros, and get Giant out of the
> fast path in all of the kernel. Then if Giant i still around as a mutex,
> it won't have that much impact!
>
> Warner, what is the status of your Giant work?
>

Stalled a bit for want of time, and waiting on the big ball of goo that's
the x86 keyboard / console driver to reach some kind of resolution.

I posted https://reviews.freebsd.org/D23388 a while back, but got
bogged down removing the Giant requirement from device_busy
because there's a few infrequently used drivers that are tricky to
test that are using it. https://reviews.freebsd.org/D26284 has
the code to do that, but I think I got distracted by the quiesce
discussion which is a better way to cope, but again, involves a
number of infrequently used drivers.

Both of these reviews likely needs to be rebased, if I don't
happen to have them in a local git branch (they date from the dawn
of my git svn usage, so maybe got dropped along the way
by mistake).

Warner