Re: support for asymmetric CPUs

Alexander Leidinger <[email protected]> Wed, 02 Mar 2022 12:12:06 +0100

Newsgroups	gmane.os.freebsd.architechture
Message-ID	<20220302121206.Horde.NKFkA1iMzx7Q3sIoiU3Gkrw@webmail.leidinger.net>

Quoting Daniel Ebdrup Jensen <[email protected]> (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 [email protected]: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    [email protected]  : PGP 0x8F31830F9F2772BF

signature.asc (application/pgp-signature, 851 B)