Date: Wed, 24 May 2023 08:28:50 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Kyle Evans <kevans@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Mark Johnston <markj@freebsd.org>, Hans Petter Selasky <hps@selasky.org>, Warner Losh <imp@bsdimp.com>, Konstantin Belousov <kostikbel@gmail.com>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD Message-ID: <20230524082850.ffc8793b6bb1b47325ae0139@bidouilliste.com> In-Reply-To: <CACNAnaHvz-BFRW193ZEr1wx%2BO7G_%2B1B68yHQ-TpYbX6=ferA1Q@mail.gmail.com> References: <b0461320-fb92-95cf-609b-3550eb30a589@selasky.org> <CANCZdfowk1oQnw30hk%2BA-pSq0_QK52dahF6x3AUi=A76J18R9w@mail.gmail.com> <ZGq03_RdpqXppA-h@kib.kiev.ua> <394775eb-1000-60d9-2ddd-5c2aca6c99ea@selasky.org> <CANCZdfq4D3N12c6h_Hy7Mvyg_d%2BpZBnN39CvpDU14-qDEhMFXQ@mail.gmail.com> <b6300144-41bb-53c9-b103-117547ff8a27@selasky.org> <08ba506f-66c5-35eb-e992-ecf9dfeccf93@selasky.org> <ZGy_3w4nUmTNxTm9@nuc> <eac6b35d-0d00-45d3-5925-7fcaccedac7e@FreeBSD.org> <CACNAnaHvz-BFRW193ZEr1wx%2BO7G_%2B1B68yHQ-TpYbX6=ferA1Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 23 May 2023 18:53:47 -0500 Kyle Evans <kevans@freebsd.org> wrote: > On Tue, May 23, 2023 at 6:39?PM John Baldwin <jhb@freebsd.org> wrote: > > > > On 5/23/23 6:30 AM, Mark Johnston wrote: > > > On Tue, May 23, 2023 at 08:00:53AM +0200, Hans Petter Selasky wrote: > > >> Hi Warner, > > >> > > >> When you make systems and use them, you get bound by them. If a syst= em makes > > >> a certain solution advantageous, it gets chosen, independent if it i= s a good > > >> solution or not. > > >> > > >> The reason for our disagreement is simply this: > > >> > > >> You are thinking like a politican and want to be popular in the curr= ent > > >> system of FreeBSD. > > >> > > >> I'm thinking like a mathematican regardless of what makes me popular= in the > > >> current system of FreeBSD. > > >> > > >> > > >> Why not state that from the start? Implementing Quick Sort in qsort(= ) and > > >> using that everywhere is a political decision. > > >> > > >> This is not a technical fight, it is a political fight. > > > > > > I don't agree. From my point of view, Warner's position is the > > > pragmatic one. We have perhaps 2% Linux's number of active > > > developers[*], but we are relatively much larger in terms of > > > performance, code complexity, size, etc.. > > > > > > Layering and simplicity of design are some of the main tools we have = to > > > counteract this imbalance. It helps reduce the amount of time > > > developers spend on bugs that aren't directly related to what they are > > > doing. It helps us think about and predict the behaviour of the syst= em > > > using only intuition. This tradeoff can mean that we do not provide = the > > > best possible performance in all cases, but that's often a reasonable > > > tradeoff in this rather non-mathematical world where we do not have > > > infinite resources. > > > > > > The existing SYSINIT bubblesort is a good example of this tradeoff. = At > > > the time it was written, it made sense to choose a simple, "good enou= gh" > > > solution and move on. Even now, this simple solution just works and = is > > > perfectly acceptable on the vast majority of systems where FreeBSD is > > > deployed. > > > > > > I see this attitude reflected in Warner's and others' replies, and I > > > agree with it. I suspect that Warner, rather than wanting to be popu= lar > > > per se, is replying in his own self-interest, which is to spend zero > > > time debugging anything that might break if we start doing extra work= at > > > compile time to sort linker sets. > > > > > > It could be that some specific use-case will make your proposal more > > > attractive. I don't mean to suggest that the topic should be closed > > > forever. So far though, having read the thread and D40193, I'm not > > > really sold. > > > > > > [*] I'm sure this number can vary wildly depending on how you define = it; > > > my impression from reading Linux lists for a while is just that we ha= ve > > > way fewer people who understand core pieces of the system. > > > > +1. > > > > Also, the concern over the runtime for the potential worst-case for qso= rt > > seems _way_ overblown compared to the actual unsorted arrays one will g= et > > out of the linker. The only possible downside of qsort that matters in > > this case is the stack usage. > > >=20 > IMO sorting at runtime is a minor feature by itself, too. I mentioned > in one of the reviews somewhere, we have in the past have had bugs due > to poor specification of sysinit order within a subsystem -- I'm > recalling a specific one that wasn't even that long ago, maybe three > or four years, that manu@ had hit because he did or didn't include > some device in his config that ended up shifting link order of other > objects and reversing two sysinits into an order that wasn't actually > functional. Yes this problem was a pain to debug (I mean just to understand the actual problem), and iirc it was never solved, I only had the issue on one machine that I don't use anymore and the problem went away and re-apears from time to time when sysinits where added. > We can still add some bits to test that (preferably a > tunable to reverse order within a subsystem rather than having to > re-link the kernel) even with sorting at link-time, but it sure does > look a lot less fragile if we have to sort it anyways and we just > reverse one criteria. >=20 > Thanks, >=20 > Kyle Evans >=20 --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230524082850.ffc8793b6bb1b47325ae0139>