Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Mar 2022 09:03:06 +0000
From:      Bob Bishop <rb@gid.co.uk>
To:        mike@karels.net
Cc:        "freebsd-arch@freebsd.org" <freebsd-arch@FreeBSD.org>
Subject:   Re: support for asymmetric CPUs
Message-ID:  <310CBE30-6E24-4F17-9E52-76E067E8BF52@gid.co.uk>
In-Reply-To: <202203040139.2241d20M045464@mail.karels.net>
References:  <202203040139.2241d20M045464@mail.karels.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Hi,

> On 4 Mar 2022, at 01:39, Mike Karels <mike@karels.net> wrote:
>=20
> Replying to several messages, including my own:
>=20
> Although several people mentioned energy efficiency, that is not my
> immediate goal.  At least with the Alder Lake CPUs, I suspect that the
> difference in energy use between low load on P-cores and E-cores is
> small.  These are not especially energy-efficient chips; the i7-12700K
> is rated at a base power of 125 W, with a peak of 190 W.  Instead, I =
am
> more interested in system throughput and sensible placement decisions
> using fairly simple algorithms.  I plan to experiment with starting
> most processes on E-cores, and promoting to P-cores as soon as they
> start using much CPU time.  This should reserve the P-cores for the
> processes that most need them, and keep the processes with lower
> utilization from interrupting them and disturbing caches.  In any =
case,
> I'm hoping that simple algorithms can beat random placement.  Naively,
> I hope that similar strategies would also lower power consumption for
> varying workloads with mixed core types, although not as much as
> algorithms that were more sensitive to efficiency of different types
> of workload on the different cores.  I haven't decided yet whether to
> consider threaded processes differently; the E-cores are supposedly =
better
> for threaded processes.
>=20
> I also don't know if/when I'll experiment with Intel's Hardware =
Feedback
> Interface; it will obviously depend on availability of documentation =
or
> example code.  In theory HFI could yield quicker placement decisions.

Section 14.6 of this for a starter:

=
https://www.intel.com/content/dam/develop/public/us/en/documents/253669-sd=
m-vol-3b.pdf

> Any additional input welcomed...
>=20
> 		Mike
>=20

--
Bob Bishop
rb@gid.co.uk







Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?310CBE30-6E24-4F17-9E52-76E067E8BF52>