From nobody Tue May 23 23:53:47 2023 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QQrkb4Sggz4TCqB for ; Tue, 23 May 2023 23:53:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QQrkb3Wqzz4F4k; Tue, 23 May 2023 23:53:59 +0000 (UTC) (envelope-from kevans@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684886039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aTjA7O/scUux+gbUxBG9/6Ns49Si57J2pV2eaGRTZI0=; b=klVVXatZ+7UK/OgIqrUe4KmDMxEeYIEwwN+ieUJak5D8q6Cs5GUxelE48Mf9DmMLqraDh7 lukfealro5vclUo6zTTUB2zQKNCcaB3sVvbrjAo08e2K0xsZmblewHTYfHkrHVP27GT03D u5nGgjb79I0TaWoGKejP0lXEtp6IYVXdLvI9fNvZfypr8Frn9g2nW39dBXVOL7QZD31Byp OlUuzFExsdM67HVpJD533bxGB+N55FA6JuU4thpf9N/cjSTpiEwG4htKpwkqKF1ENQ4p4/ QAHhpu0lkgJ3MCsuOnOBEBR4LkR55hZZFz1gJhG/bfdGOHskyEwu8NAet3qriA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684886039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=aTjA7O/scUux+gbUxBG9/6Ns49Si57J2pV2eaGRTZI0=; b=kNjuRtzM3ruKbJEn9DdaLDH9i5+7j9uC3atta3PykuCLegtSZUyh9hvKb4X0Vt6LSe8htv 44E5/XfRk1JHhrxwcGUOcdLIy4UfJTCW/qtc9Gtecj5zomOqK9TYapvITHpMWr7vvpEgWS ve47/+jhxtKGHE7QUsxk9cSK/N4lYDmSsbGN5vYUTVzQaJWuEaOwH0rFv6/q4/MUtfTx7f DYuCw8a9PfUjtRpu5ICP+HWol1rcNrmJ+G22AGJJ4ph+tyzUkvS7yot5NSM12b+TSb1PKl NE3BHnF8Bb0vjTvClrvT9xkZNeACqirz6w8nwN4Mq/+ksQ7+j25bsb5lRZ4z7A== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684886039; a=rsa-sha256; cv=none; b=HL50AfF4opEBy4gNUMka79P8pnUxaBibU9mpakRjnkESFnPZsxlTKtcPIi8VNzmwbYP5cx JpxKVdYSfITAdiU6iHBKyEC1I0pWnbnpaqYMDhD/dNs/y6S/kGc0Vq4sj3Xk10Q1/4eKva g7yFXYsQ9Ad0iSS8EH9PyXRj3kuJbPB78GOs4utE+Iv9tjDPcjl8wYKowkl6SJCC/B5eKB gpq/G+fhKpW0LWCiuV5OHdBoEgpzDiVD84sjW1bqRwt2wx9EX+tkkILL6g96gdGice0yNM 2NErc2biFKtLIV1juNXj3uu3NIIcEW7R4qQJfKroO1Tw08jaWge49KejXLXcyw== Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QQrkb2FQmzkQs; Tue, 23 May 2023 23:53:59 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-3f6a494810fso2993481cf.1; Tue, 23 May 2023 16:53:59 -0700 (PDT) X-Gm-Message-State: AC+VfDz+ifmrLkRdI/PzrQhtcfH1DB0AJ9eLN8SBg3+7YoGMYnTfEeFg Zz1hJ/T9d11o9XNXhZsF2w74tchd6ymW9aVW0yo= X-Google-Smtp-Source: ACHHUZ6kPWMZf9rI+upa7qDDQtaWgpALKUOwhrAyGC2o8w+Op39YKejgML4V5hGM6YLe5RhcmBKrrsOSQUWvifU35/I= X-Received: by 2002:a05:6214:29c9:b0:616:5460:aafd with SMTP id gh9-20020a05621429c900b006165460aafdmr23467964qvb.3.1684886038808; Tue, 23 May 2023 16:53:58 -0700 (PDT) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 References: <394775eb-1000-60d9-2ddd-5c2aca6c99ea@selasky.org> <08ba506f-66c5-35eb-e992-ecf9dfeccf93@selasky.org> In-Reply-To: From: Kyle Evans Date: Tue, 23 May 2023 18:53:47 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD To: John Baldwin Cc: Mark Johnston , Hans Petter Selasky , Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Tue, May 23, 2023 at 6:39=E2=80=AFPM John Baldwin wrot= e: > > 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 system= makes > >> a certain solution advantageous, it gets chosen, independent if it is = 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 curren= t > >> system of FreeBSD. > >> > >> I'm thinking like a mathematican regardless of what makes me popular i= n 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 system > > using only intuition. This tradeoff can mean that we do not provide th= e > > 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 enough= " > > 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 popula= r > > 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 a= t > > 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 have > > way fewer people who understand core pieces of the system. > > +1. > > Also, the concern over the runtime for the potential worst-case for qsort > seems _way_ overblown compared to the actual unsorted arrays one will get > out of the linker. The only possible downside of qsort that matters in > this case is the stack usage. > 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. 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. Thanks, Kyle Evans