From nobody Tue May 23 23:39:52 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 4QQrQM1ZLLz4TBnY for ; Tue, 23 May 2023 23:39:55 +0000 (UTC) (envelope-from jhb@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 4QQrQM0xnGz4CNM; Tue, 23 May 2023 23:39:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684885195; 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=ANDFwIsjnfTa2Uf6ab334d9Qyf4SCSFBbviNVGXMRyA=; b=JxSYz2fWZANGH+snlpwfcAYYGlcGkR7fsHCnK6HxFaPtvZGGXU2UwijZFfCYkXq9TIfqoy ufanW6JWtnfQm+btNAm5bNqN1Uh4EAfs4Gudwl04uqykemZ5NLC8NBluH7zQXQR1zn6uwk BsvcRqw84u/8rQfUsjtTKZSFdJpv9QxVlLKOhMvOWb7nZge57xvssbWHAO4W8tkJFQr1xM BCNUHyYCdBde2oRdtNiJQV8xwIQSjN51a6Fs4QaNtW2ZcN9NSsyztM2xwtrrts5A3gJQjw ILw5/vkTgTOh//WOKtDKnsaYnXhF3Vm1QEubv1cn86a/WTHmSV5zaiPPqTPJBA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1684885195; 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=ANDFwIsjnfTa2Uf6ab334d9Qyf4SCSFBbviNVGXMRyA=; b=NgONjXro5ubccETAJ29e5vnb10oBA1EUauUhqIUAL9JCHg/bmvTSfBYMlppkE/ydykdEzw fx/UZY8WWZbR2e1MOuJ7xomzDrkvRhlON5g+WaRb1hhCTiNdPMqXnbv/FLzEjL8XSZ831M CYi+uLoMsKRcXfJJQVqEPfMhKaLhjFwcowlfZzOFQoLkaekb5WYkVgE9OyWkx0Wpm7qWDz JEly7CRk3E5bNkflB6bUQF8DS+4of5mQq3RCwuAIJbvbpJi+DVqFCEAQjPHpcR1S47BEjR daFafLTJfbaapfh+4pzVrwXu/krPudWLzSjVFwyZg/IASakuRYq65UWZJHe/SQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1684885195; a=rsa-sha256; cv=none; b=CQGk0su+V8hX74DlPQypURTOeBfC9fbH0kvL6mwOTKN1hMNIkgRXgtcWslZcrMbboJJ5/b vTEkIpyECZBn9uahBknQRyBPI7/wdYwM+UkLn/pkivjQvGN9xNKQteVSFvuTkytdNeZM8h vQ850vuOrG5kRKpErRfE3Ec2Kcu6HLEVy0T5KqwfNkszpKmiIQan/FG1fF1+DYM/2sjtoy Fi1qk0xcmTji8XUOuFiJcWAjX8LDl6/sJUUz+yRGnwRU1iz/wa1Cmuf1DOQOh7YFz0aDTZ Zm2KH8mroyAuG+HQYlENfUdhI5+rfNWFV1z4Lk/vx0Ax1oyeg3M31WAdAtAoLQ== Received: from [IPV6:2601:648:8680:16b0:74c7:61ed:2261:6ed4] (unknown [IPv6:2601:648:8680:16b0:74c7:61ed:2261:6ed4]) (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 did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QQrQL33QtzjWS; Tue, 23 May 2023 23:39:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Tue, 23 May 2023 16:39:52 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Mark Johnston , Hans Petter Selasky Cc: Warner Losh , Konstantin Belousov , "freebsd-arch@freebsd.org" References: <394775eb-1000-60d9-2ddd-5c2aca6c99ea@selasky.org> <08ba506f-66c5-35eb-e992-ecf9dfeccf93@selasky.org> From: John Baldwin Subject: Re: [RFC] An idea for general kernel post-processing automation in FreeBSD In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N 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 current >> 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 system > 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 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 popular > 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 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. When Colin first mentioned this, my initial thought if we wanted to be cute would be to use a post-link tool like kldxref to sort the linker set, but such a tool would actually be rather painful to write and fraught with all the peril of the current kldxref tool (which is not yet a cross tool). The patch to use qsort by comparison is very small and easy to reason about and maintain. -- John Baldwin