Date: Tue, 07 Feb 2023 08:09:26 -0600 From: Mike Karels <mike@karels.net> To: mike tancsa <mike@sentex.net> Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org> Subject: Re: Raptor Lake / Alder lake on RELENG_13 ? Message-ID: <3E515D30-958F-4483-B02C-C124C6D108F5@karels.net> In-Reply-To: <8b609a35-cd3c-b191-ec8e-a0819cfc013e@sentex.net> References: <0600fbab-035f-fd23-a6d7-27cd2f58665e@sentex.net> <C95CE8CE-F545-4B09-81E9-EFC5C6F6F35C@karels.net> <8b609a35-cd3c-b191-ec8e-a0819cfc013e@sentex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 7 Feb 2023, at 7:41, mike tancsa wrote: > On 2/7/2023 8:29 AM, Mike Karels wrote: >> On 6 Feb 2023, at 16:04, mike tancsa wrote: >> >>> Hi All, >>> >>> =C2=A0=C2=A0=C2=A0 I have seen a couple of commits around these CPUs= , but wondering if anyone is running 13 on these newer hybrid CPUs ? Do t= he slower cores just get disabled or are they made use of somehow ? >>> >>> =C2=A0=C2=A0=C2=A0 ---Mike >> I have been testing the changes on -current, and they are working fine= =2E I have not tested on 13, but I would expect the same result. The wo= rkaround is on 13-stable, but not yet a RELENG branch. Presumably it wil= l be in 13.2 when it is branched. If no one else has reported, I will te= st the 13.2 branch. Also, I haven=E2=80=99t heard of tests on Raptor Lak= e, but I have heard that the behavior should be the same as Alder Lake. >> >> The E-cores are not disabled. They are forced to use a less efficient= method of page invalidation. They are scheduled as if they were P-cores= without threads, but they are less used because of the shared cache amon= g 4 cores rather than 2. I have some preliminary scheduler changes that = recognize the slower cores, but there are still issues to be dealt with. >> > Thank you very much for the detailed update!=C2=A0 Apart from some perf= ormance tweaking, would you say performance overall is pretty good, or wi= ll the scheduler enhancements need to be made still ? > > =C2=A0=C2=A0=C2=A0 ---Mike Performance seems very good to me. As far as I can tell, the E-cores are= slower than P-cores with a single thread, but faster than the second thr= ead on a P-core. Hopefully scheduler improvements will help more for a w= orkload that uses fewer than all hardware threads. Software threading co= uld in theory be handled better by putting threads where they will share = cache, but that is not a simple addition. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E515D30-958F-4483-B02C-C124C6D108F5>