Date: Wed, 2 Mar 2022 08:36:38 +0100 From: Daniel Ebdrup Jensen <debdrup@FreeBSD.org> To: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs Message-ID: <20220302073638.o7qgisnbbixo6ezh@geroi.local> In-Reply-To: <ff3e9d1f-3631-ccc8-8d5a-320d963aadac@FreeBSD.org> References: <202203011904.221J4Yg8032167@mail.karels.net> <ff3e9d1f-3631-ccc8-8d5a-320d963aadac@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220302073638.o7qgisnbbixo6ezh>