Date: Sun, 9 Jan 2022 21:12:58 -0800 From: Kevin Oberman <rkoberman@gmail.com> To: FreeBSD Stable ML <stable@freebsd.org> Subject: Odd performance problems with Lenovo L15 Message-ID: <CAN6yY1sK%2BxOi6Hy5KXefFa9cHhmTirCOmFFanZrRF8LzYbOUNQ@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
--000000000000bfa6f905d5336418 Content-Type: text/plain; charset="UTF-8" I continue to see odd performance issues and just noticed something I can put my finger on that may explain it. It has gone from odd to totally off the rails. Any ideas will be appreciated. Normally, on an idle system I see all CPUs running at full speed. dev.cpu.7.freq: 2101 dev.cpu.6.freq: 2101 dev.cpu.5.freq: 2101 dev.cpu.4.freq: 2101 dev.cpu.3.freq: 2101 dev.cpu.2.freq: 2101 dev.cpu.1.freq: 2101 dev.cpu.0.freq: 2101 But, during a large compile (e.g. llvm or firefox), things sometimes go wonky. Everything slows to a crawl. And, I see: dev.cpu.7.freq: 400 dev.cpu.6.freq: 400 dev.cpu.5.freq: 400 dev.cpu.4.freq: 400 dev.cpu.3.freq: 400 dev.cpu.2.freq: 400 dev.cpu.1.freq: 400 dev.cpu.0.freq: 2101 And, it never changes back to faster speeds. This is while the system is idle and the temps are all back as expected in an idle system (low 40s). I suspect that the change occurs when the system is very warm. The cores reach about 90C and then start to drop back to near idle temps (<50C). This is a 4 core system, but cpu 0 and 1 are running at very different speeds... 0 at max frequency and 1 at minimum. I don't think that it is possible as that is different clock rates on the threads of a single core. Everything seems messed up with super-slow IO and processes simply locking up. They can't be killed and the system will not even shut down with the inability to terminate the "stuck" process. This is one of the Lenovo systems that will lock-up with P-States enabled, so they are disabled. I suspect that running without P-States is not well tested. As far as I know, no progress has been made as to why this happens on FreeBSD, but not on Linux. It may or may not be related to this issue. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 --000000000000bfa6f905d5336418 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:tahoma,s= ans-serif;font-size:small">I continue to see odd performance issues and jus= t noticed something I can put my finger on that may explain it. It has gone= from odd to totally off the rails. Any ideas will be appreciated.<br></div= ><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font-s= ize:small"><br></div><div class=3D"gmail_default" style=3D"font-family:taho= ma,sans-serif;font-size:small">Normally, on an idle system I see all CPUs r= unning at full speed.</div><div class=3D"gmail_default" style=3D"font-famil= y:tahoma,sans-serif;font-size:small">dev.cpu.7.freq: 2101<br>dev.cpu.6.freq= : 2101<br>dev.cpu.5.freq: 2101<br>dev.cpu.4.freq: 2101<br>dev.cpu.3.freq: 2= 101<br>dev.cpu.2.freq: 2101<br>dev.cpu.1.freq: 2101<br>dev.cpu.0.freq: 2101= </div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;f= ont-size:small"><br></div><div class=3D"gmail_default" style=3D"font-family= :tahoma,sans-serif;font-size:small">But, during a large compile (e.g. llvm = or firefox), things sometimes go wonky. Everything slows to a crawl. And, I= see:</div><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-se= rif;font-size:small">dev.cpu.7.freq: 400<br>dev.cpu.6.freq: 400<br>dev.cpu.= 5.freq: 400<br>dev.cpu.4.freq: 400<br>dev.cpu.3.freq: 400<br>dev.cpu.2.freq= : 400<br>dev.cpu.1.freq: 400<br>dev.cpu.0.freq: 2101</div><div class=3D"gma= il_default" style=3D"font-family:tahoma,sans-serif;font-size:small"><br></d= iv><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font= -size:small">And, it never changes back to faster speeds. This is while the= system is idle and the temps=C2=A0 are all back as expected in an idle sys= tem (low 40s). I suspect that the change occurs when the system is very war= m. The cores reach about 90C and then start to drop back to near idle temps= (<50C).<br></div><div class=3D"gmail_default" style=3D"font-family:taho= ma,sans-serif;font-size:small"><br></div><div class=3D"gmail_default" style= =3D"font-family:tahoma,sans-serif;font-size:small">This is a 4 core system,= but cpu 0 and 1 are running at very different speeds... 0 at max frequency= and 1 at minimum. I don't think that it is possible as that is differe= nt clock rates on the threads of a single core. Everything seems messed up = with super-slow IO and processes simply locking up. They can't be kille= d and the system will not even shut down with the inability to terminate th= e "stuck" process. <br></div><div class=3D"gmail_default" style= =3D"font-family:tahoma,sans-serif;font-size:small"><br></div><div class=3D"= gmail_default" style=3D"font-family:tahoma,sans-serif;font-size:small">This= is one of the Lenovo systems that will lock-up with P-States enabled, so t= hey are disabled. I suspect that running without P-States is not well teste= d. As far as I know, no progress has been made as to why this happens on Fr= eeBSD, but not on Linux. It may or may not be related to this issue.<br></d= iv><div class=3D"gmail_default" style=3D"font-family:tahoma,sans-serif;font= -size:small">--<br clear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail= _signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div d= ir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr">Kevin Oberman, Part = time kid herder and retired Network Engineer<br>E-mail: <a href=3D"mailto:r= koberman@gmail.com" target=3D"_blank">rkoberman@gmail.com</a><br></div><div= >PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683</div></div></div= ></div></div></div></div></div></div></div> --000000000000bfa6f905d5336418--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1sK%2BxOi6Hy5KXefFa9cHhmTirCOmFFanZrRF8LzYbOUNQ>