Re: support for asymmetric CPUs
- In reply to: Daniel Ebdrup Jensen : "Re: support for asymmetric CPUs"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Wed, 02 Mar 2022 11:12:06 UTC
Quoting Daniel Ebdrup Jensen <debdrup@freebsd.org> (from Wed, 2 Mar 2022 08: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 more than one thread at once may be interesting (4 minutes to distribute 512 threads from one core to all 32 cores), no matter if mixed perf cores are a good idea or not. The first question I have for this case is: is this an artificial case (the authors limited all threads to one cpu via cpuset and then opened up to all cpus to measure the time to get to a balanced state) which can not happen in the wild with a "normal" workload (postfix / apache / nginx / 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 thread away from a given core in an extremely unbalanced case? > 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 Bye, Alexander. -- http://www.Leidinger.net Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF