Date: Wed, 02 Mar 2022 12:12:06 +0100 From: Alexander Leidinger <Alexander@leidinger.net> To: Daniel Ebdrup Jensen <debdrup@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: support for asymmetric CPUs Message-ID: <20220302121206.Horde.NKFkA1iMzx7Q3sIoiU3Gkrw@webmail.leidinger.net> In-Reply-To: <20220302073638.o7qgisnbbixo6ezh@geroi.local> References: <202203011904.221J4Yg8032167@mail.karels.net> <ff3e9d1f-3631-ccc8-8d5a-320d963aadac@FreeBSD.org> <20220302073638.o7qgisnbbixo6ezh@geroi.local>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format and has been PGP signed. --=_CYpbMvSfKQ4eUIKrPlyXljl Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Daniel Ebdrup Jensen <debdrup@freebsd.org> (from Wed, 2 Mar=20=20 2022=2008:36:38 +0100): > 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]. I had a look at [3]... looks like experiments in terms of migrating=20=20 more=20than one thread at once may be interesting (4 minutes to=20=20 distribute=20512 threads from one core to all 32 cores), no matter if=20=20 mixed=20perf cores are a good idea or not. The first question I have for this case is: is this an artificial case=20= =20 (the=20authors limited all threads to one cpu via cpuset and then opened=20= =20 up=20to all cpus to measure the time to get to a balanced state) which=20= =20 can=20not happen in the wild with a "normal" workload (postfix / apache=20= =20 /=20nginx / mysql / ...) except you play around with cpusets? In case someone with some ULE-knowledge reads this: Do I read our code correctly if I say replacing CPU_CLR(high, &hmask); CPU_COPY(&hmask, &lmask); by CPU_COPY(&hmask, &lmask); CPU_CLR(high, &lmask); in sched_balance_group() would result in migrating more than one=20=20 thread=20away from a given core in an extremely unbalanced case? > 1: https://cgit.freebsd.org/src/tree/sys/kern/sched_ule.c > 2:=20=20 >=20https://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 Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_CYpbMvSfKQ4eUIKrPlyXljl Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmIfUQUACgkQEg2wmwP4 2IZC5Q//Wd05meIb/8YE+LwKnwTUlSzszR7KLvLC0iTCfJdCEq3BTbM2ctMwAQTg 1RU7QPUs0lJV2FrwTWW+AG6a71I7eH0BVzv47melrtR5bpD+5JnK7D15Q729Ncj9 pXIY524XrqZ2S1Q2QUvgd9/DmX/drRE1JVC6AXvDSoQc1AKeYMM4RIcgF6Ew932Y NYyUwUj8SEmOshM2hlJzs5uW/XIKz+FTErc0zgkRhb2jR50TfxpxHRSjPwQtkkKJ 41J+9+XLJ+W++cNye/wvV/SMJ8VKqbWJN+bo+DfGAW1Fu0Al0N6/fP6ypb1iAvxZ 9thZRXOnVjk/LAHI1cJnpEumt9m43tQ+ZsHiJw6sN5ZIdhXnIDtGeh2fWW1zYhHe w1uSebNVT7LUS5dMD26Abpw21f/9vZ4lFMrc7Ce+//L3s7ivCC1bWVwRygBhEGbN wnSvfrT1WbW3G7rO7c6Azwmsb1+nzIH/BbVocjBUUgYjsz1pSixGecigKQzkGVQd DU00u6l/dWk2TIhKNGfkZDXI5/6hnzNK+EDMflSJzXmcBmvyjR9AGyl5kMbK/Wt5 vGAp+2uRGdGNQv32ZbEhn5bxXsis3gAMaYGwPlMzEMKqmdvHl2Ed/GaYNR9kXkwa IpPl6IELatFh067MyPIMdl4ZnfK7YZAxIeuCc2Ekyw862JgxG0g= =g1dK -----END PGP SIGNATURE----- --=_CYpbMvSfKQ4eUIKrPlyXljl--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220302121206.Horde.NKFkA1iMzx7Q3sIoiU3Gkrw>