From nobody Mon Jan 10 05:12:58 2022 X-Original-To: stable@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D3B411946DED for ; Mon, 10 Jan 2022 05:13:22 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JXMRQ0Mj8z4Yql for ; Mon, 10 Jan 2022 05:13:22 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id h10so14306200wrb.1 for ; Sun, 09 Jan 2022 21:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=6STaXLCx6WxfWpprWGMnCNI8rCIUp4U/acbYfzXnhuI=; b=Ev9k0S99zVCLoGzEhXHxFl9ZEHRuWAEAIOkR3FtETD7a4H0FgBl4JuJvArMtjSGyQa fFdUPwdbrs1hZRd2MnlEZzSQm0RkhvT2VC2m7o2PpAwjrIip5AF5oeJmP9vBFOWNI/4M ecjL9a0+pjDJK/apzEJfglpWq2nJbc0s8M/stKownFfQV7YaP393xvG/xfL6gpye9MWu KQUJ9ingw2qRPU1odZo1yuD9UsIce/Ou8TxZINmm9pTy/xn0GNKdCNPprzMgOGskaLmU dJ9x0uezytW7tmPavGf2O/sMjXqTVyCgZhx99Kak34VhDxuLsFtrEWNAXlD66wOb+ydW Q46w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6STaXLCx6WxfWpprWGMnCNI8rCIUp4U/acbYfzXnhuI=; b=cwePZX3tzQIv3Rh04d1irlDsYQHDva0Xu2hQzChetykrEU0YNQHWNyEnc2EbTj+Vk8 As8KoXjgQQ1Njyt4J52X3bKI3SjLt1LoOQ/Aq8zMBjPnr8/fyakRYFwtNJgh7r2m/JoL LbPqwTufYhbzt4aeq6H8KM33UNaCBaYcV2PKfQ2DDh1OIxMs7aOChtkdndnANAnYxtMd 1WgLEjuotkKMPGTwVPcsclxNV8iMkatdu/rXPZS4c6BTc4IpjokgV12xi/8Ibe78eV1T +4zzniC83g1/J/ZzxLMa3HlZ3XH3Ul6RFaMM7msXthNOMWcYE/zJ6oFHkhD3wHDBSky3 wVxw== X-Gm-Message-State: AOAM533/341ual/FmSjw9xy262MYrd2Lc3phIfym6EUnylOkchUPaWc9 zja6uKIfZQgkTcHMETOE77Dor6FTUauSd55QbRs1Z3A+Ivr1sQ== X-Google-Smtp-Source: ABdhPJy/Xi644khVtJ9zNdfMqw7AJ/5AbFqyRFTwJxnJ6LazmWsfPkjhXPV7ckKZ+vbUYvs9A6w1sPm4GHeqCwzi4lE= X-Received: by 2002:a05:6000:15ca:: with SMTP id y10mr61623083wry.718.1641791593882; Sun, 09 Jan 2022 21:13:13 -0800 (PST) List-Id: Production branch of FreeBSD source code List-Archive: https://lists.freebsd.org/archives/freebsd-stable List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org MIME-Version: 1.0 From: Kevin Oberman Date: Sun, 9 Jan 2022 21:12:58 -0800 Message-ID: Subject: Odd performance problems with Lenovo L15 To: FreeBSD Stable ML Content-Type: multipart/alternative; boundary="000000000000bfa6f905d5336418" X-Rspamd-Queue-Id: 4JXMRQ0Mj8z4Yql X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=Ev9k0S99; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of kob6558@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=kob6558@gmail.com X-Spamd-Result: default: False [1.80 / 15.00]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[stable@freebsd.org]; NEURAL_SPAM_SHORT(0.55)[0.547]; NEURAL_SPAM_MEDIUM(0.96)[0.956]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FORGED_SENDER(0.30)[rkoberman@gmail.com,kob6558@gmail.com]; NEURAL_SPAM_LONG(1.00)[1.000]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[rkoberman@gmail.com,kob6558@gmail.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --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
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.

Normally, on an idle system I see all CPUs r= unning 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: 2= 101
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=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).

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.

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.
--
Kevin Oberman, Part = time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
--000000000000bfa6f905d5336418--