Date: Tue, 26 Nov 2019 11:21:20 -0700 From: Warner Losh <imp@bsdimp.com> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Killing Giant for 13 Message-ID: <CANCZdfowGPBgp14aaJ15GnYOkRb_C91AeRqFY-axqu%2BCOScz8w@mail.gmail.com> In-Reply-To: <201911260917.xAQ9Hcf1001914@gndrsh.dnsmgr.net> References: <CANCZdfr0CpDBQ6QWJ_CTtOLW6EwAke_Vr_imqa5=GBzRAoa6eA@mail.gmail.com> <201911260917.xAQ9Hcf1001914@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Nov 26, 2019 at 2:17 AM Rodney W. Grimes < freebsd-rwg@gndrsh.dnsmgr.net> wrote: > > I'd like to kill Giant in 13 and schedule a firm removal date. > > > > The issues are (a) old drivers that aren't MP safe (b) some console / > ATKBD > > interactions (c) newbus and (d) a few stays that haven't been > characterized. > > > > (a) should be deleted or updated before the deadline > > (b) should be fixed by $SOMEONE[tm] > > (c) there's some work underway to refine the locking protocols to allow > one > > to not have Giant held (there's real questions about how effective it is > > when things sleep or contend) > > (d) I'm researching. > > > > Would there be support for setting a firm deadline for Giant removal of > > around June 2020? This would be months ahead of a speculative 13.0 > timeline > > (Earliest would be December 2020, latest would be maybe October 2021, > the > > exact details aren't super relevant for a June target date). > > > > This is a preliminary inquiry to get a feel for support for this option > and > > to gather additional issues and requirements. Comments? > > I see one reply to this, yet am seeing commits killing drivers, that > at least on surface appear to be not so old, and possibly relevant. > > Though I have no objectionion to the removal of GIANT, I do have objection > to what appears to be execuction before research and discussion, especially > as I believe the item would of be under (d) above, as I do not consider > a driver that came into the tree at 10.0 "OLD". > If we drop Giant, we can't support Giant locked drivers. Giant is a funky lock designed to be a virtual splhigh for the driver while holding it (so only one thread can be executing with Giant, but if that thread sleeps, Giant is dropped unlike every other lock in the system). Sometimes converting code to a normal mutex just works, other times not. It's one reason all drivers haven't been converted. It's also a big wart on our system because it is so "special" that people looking at Giant locked code tend to think of it as a mutex rather than as a SPL and make mistakes. However, the hpt27xx driver turns out not to be Giant locked on versions of FreeBSD >= 10. So it's off the list. Scott has backed that out just now. Even so, there's little evidence of its use in the wild, so it's not a top-tier driver... But this is an iterative process, and sometimes mistakes are made. As an open source project, though, people can look at the code to double check the analysis if there's an interest in the driver. People can help by looking at things on the list to see what the efforts would be to convert the drivers. The more eyes we have the better. But if we can find no-one to test the fixed driver on actual hardware, it's been our tradition to commit the locked driver (which may be broken) and then remove the driver. The idea has been that if someone shows up with hardware and tests it, we can easily reinstate it to the tree. So far, though, none of the drivers John Baldwin locked checked in and then removed because nobody has time to test it had anybody showing up with test results after the fact... The bottom line remains, though, that no matter when a driver arrived in the tree, if it's Giant locked and we remove Giant, it's going to go. There's been a 20 year, almost, transition period allowed... We're well past the time to complete the plan... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfowGPBgp14aaJ15GnYOkRb_C91AeRqFY-axqu%2BCOScz8w>