From nobody Wed Mar 2 07:36:38 2022 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 9DA5F19F2950 for ; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (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 "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4K7mCD45gWz3pvW for ; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) (envelope-from debdrup@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646206600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VuH/mAartVRdpimfnAViLPVubyFhHNtNDD6JHMs//Gs=; b=tw1GNDY7hlgIVJZ2VWJ8Oa/lS6tgyJPq9pTF2omFIuMK7Y8RuT5OzTE4F+PloDRXFMaWju JIu93IZ2zHXf5cNrUnoxkiCJiGGnsDDcDHvJmMRBz9dAhrtIxpgJVfh7oXMQkWLQs+Qx72 9KiLL8cMk8Gd18zRk0FqC9w5kwZxm7Gx/Fzk1iZvVTaRW0+BDbAQKl8r+qMeMctW20I2y7 Zw4ZzGFApCmsIeTEtnaBCppavX/H9eH9RoTX7hEvy28yQ1Nj/pgJ1oGKuHBbQ9yEeVEolV aX2PTUVYVezjC3X4YVv+eVXqpca4fHzoZdTvphFpWioLDuXeRagLVDNfeu+V/w== Received: by freefall.freebsd.org (Postfix, from userid 1471) id 754C5ABF3; Wed, 2 Mar 2022 07:36:40 +0000 (UTC) Date: Wed, 2 Mar 2022 08:36:38 +0100 From: Daniel Ebdrup Jensen To: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs Message-ID: <20220302073638.o7qgisnbbixo6ezh@geroi.local> References: <202203011904.221J4Yg8032167@mail.karels.net> 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 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nmulnnf74c4d7qy5" Content-Disposition: inline In-Reply-To: ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646206600; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=VuH/mAartVRdpimfnAViLPVubyFhHNtNDD6JHMs//Gs=; b=eqXQXhBHTeU7aQcU2Natj3eKILD9vBWFOg2zqXrzoa9RKthWDJ+BUIKcIJlKLt/L85lNhV et7QjTZnyQ7AzCl9O7JmKt6AaswT/AgRvNfxIWs9/im+YleUUykQMmK2faCWL14DChp/TZ JhDVsV3Qj81gt6A9hPZoKfSJjfCUxZvBhgxGQ4mOGhRNdJ9byqZ/CSrDCPqCkImbGf5QUy Rn8dVaQmkdFJpjiCAFFFLPS5L/bGuNoQvUUIast9XlW/IWCehRlkKapdsHsRzWzMpQxR1I GJWrWYLO/LHrHNBLWGpop8TCXfOuASx8GzJxQH8BLSkuQJvP6OUp32wrSqzZQg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646206600; a=rsa-sha256; cv=none; b=YxEPHaFhxnunGmXIKzoM20KAAMDbLymzuAn+y1HVHEcc5otq5V9d0mM5FN1p+gy8bOyBlF sWcD7NW2clU/rt4Bo/8gn0XybP/VOqExkEs4HWsD99kzeqezhAkZi/29AHrZBmJr5vL8kE dRoQqDR6mismFG9KrAm3fnaGQddJHbh9F51UaW31bJwkGiXfYomgsKd/AngOmuurX9jImz lbV81jMW5IpxPZ7Yp1BNu+L3u08hgBsCs48Xkc9KwgFG62+IFfbdgVM8Kq08auYhJCp2Wm MA6Ac4n78JEgQsbMyGJbRqNo8Vkwc1/X4RTfGXoUPWVitOwkGFXMRaa7PgpVRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --nmulnnf74c4d7qy5 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline On Tue, Mar 01, 2022 at 10:05:28PM +0100, Stefan Esser wrote: >Am 01.03.22 um 20:04 schrieb Mike Karels: >> If anyone has thought about this or has done any work on it, I'd be >> interested to hear about it. > >Not identical to big/little scheduling, but IMHO related: > >Regards, STefan Hi folks, I should preface this by saying that I'm no expert in schedulers, but that even I've spotted at least a few issues with Heterogeneous Multi Processing - which so far as I know is the generic name for ARM bigLITTLE, Intel P+E cores, and whatever else AMD, RISC-V, and IBM come up with if the technology matures. The existence of cores which are meant for energy-efficient use implies that the scheduler can keep track of when something is energy-efficient, which in turn means that in an ideal world the programmer would give the compiler some kind of hints, there's some information that lets the scheduler know if something will use less energy if it's run on a faster processor vs taking longer on a slower one, and/or that there's some other magic trick that'll make this sort of thing work without adding potentially thousands of lines of heuristics to our scheduler [1] which won't necessarily make it faster than another scheduler [2] which has almost an order of magnitude more lines but isn't any faster and can be slower in certain use-cases [3]. And all of that doesn't take into account however many person-hours will go into actually programming all of it. All of this, of course, assumes that HMP isn't just a bad idea that's been allowed to fester a bit too long - something that I'm not personally convinced it isn't, and I've seen no good arguments supporting it other than something that amounts to "these folks are saying it will have been a good idea in X number of years". I'd love to hear what scheduler experts have to say on it, though. Yours, Daniel Ebdrup Jensen 1: https://cgit.freebsd.org/src/tree/sys/kern/sched_ule.c 2: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/sched/fair.c 3: https://www.usenix.org/conference/atc18/presentation/bouron --nmulnnf74c4d7qy5 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAmIfHoZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87oTcwgAq532GcXDEMulK87Y9MZElJbHRU1dS/S41vXWdoL5ZT7an24OfyI6hDfv 16EX+QxJ7+4YMLHi3eMD320r10gprZF4GQT6o3lvwWAOhp8/rPcqqZ+rMy1KnjN8 x79pSV4e4PvSPVfpnqfsY8bB1aQzEHkkvRIClNfUnJzYSMrq6pMlVat7cDJKoU/1 KdI/ipnzNvkfzXXXCVjXocUf3hj2MgSkr1XwqcjytVgBOVMnZzs481eJSlZeK1Qa WXDWKrtvP0cTwCuIsfmWbKzMZ/iYv7ge3rmjJWawbtuEQmutmietM2OB8F8Y0zIY 4W4ImYOwpIsUb/QDzG5a73pUcopq2g== =f2Ct -----END PGP SIGNATURE----- --nmulnnf74c4d7qy5--