Re: Killing Giant for 13
- In reply to: Hans Petter Selasky : "Re: Killing Giant for 13"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 13 Jul 2021 20:27:46 UTC
On Tue, Jul 13, 2021 at 9:13 AM Hans Petter Selasky <hps@selasky.org> 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