Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp651662ybc; Sat, 23 Nov 2019 05:50:40 -0800 (PST) X-Google-Smtp-Source: APXvYqzBdbiebE6ewiTlJ3Ajv6x4y1XeXahu9AGk0kuxCGLMUKQqhlxCTKnAundRY3+2fbrZ1nhk X-Received: by 2002:a17:906:5a83:: with SMTP id l3mr27746072ejq.194.1574517040880; Sat, 23 Nov 2019 05:50:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574517040; cv=none; d=google.com; s=arc-20160816; b=1Ct2YYhmS0eqhfRkc3OYGMj0+MN2CR9UJfSR1h0/0v8g+OPFn/y+p4N/GfZW/0sLi2 ud4LW/kLfpCgSE2FbjIlnl8lg3QBNeMcUAkRurLJiceOc9ATCML7pIl7KRtlDztdxdp/ 1kJlmMTsWEjTQquAycdr+yO8W/KxS9QoRPNOK7kOQC+oPgc+X8pJCcVHhMwL62L3rgrQ 4f49cZXKc8/t17CGpiWbz7Tl/9hKPLjLXiYt3NW1lsC3Op2tjZt9MwJ7xgwlat+zXAiH 9b92yoNYDwFTVMJl3cK0IpX3lY0skuzMPppUJ5RbQD37aXZWTdGOw6XCdBOSNqlqrLrJ TPYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature; bh=9KeyRkpDZVKgACFsR86ZLUtYw0/zMx2nBt8gsEy4VkY=; b=o2p7ikSmCyJwh8q5UphodWsNA+d/AAn0B+hSr+9hzmxzDGvrhvCwzCh7pdtsA9nVNv N1YHccg0yZIsUXa9grB9kMaf6mug53qWkjZxfADplko9CglWV1ciCZPg5hguYqWWaP6D Wx4SA8ehLtoaXa/tL0FIOhYU3zUAZ/2ZRBCrhtWHuWs+fdaDSUyWtnTQAMeLW1EnkHzJ jBrbSBpuBlRnsdZ5E8I6UCqNpqE1/ogTfF05ObHTp67/9mWpUBhno++K0CfLW7HVFkos Q3l8wJhCifETcAfpAufHHcGYOnFxglpdCB3SxvovK882Zeu4J1XSzS8/COsgqUdpIh/N 7Rjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X++VSGfl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x16si717744ejw.375.2019.11.23.05.50.03; Sat, 23 Nov 2019 05:50:40 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=X++VSGfl; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726719AbfKWNoF (ORCPT + 99 others); Sat, 23 Nov 2019 08:44:05 -0500 Received: from mail-oi1-f169.google.com ([209.85.167.169]:46427 "EHLO mail-oi1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726451AbfKWNoE (ORCPT ); Sat, 23 Nov 2019 08:44:04 -0500 Received: by mail-oi1-f169.google.com with SMTP id n14so9072062oie.13 for ; Sat, 23 Nov 2019 05:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9KeyRkpDZVKgACFsR86ZLUtYw0/zMx2nBt8gsEy4VkY=; b=X++VSGflwEacfUteQZIrH4O+VY073wTqPChEwiGpiCNbfMGWfQ7SrOYVbdZnqzxkcs TUveITXphURovJtfOpl7td3VAE1VQ2QZsAclBKF6vlgC0fNV/yPo/A9Lefsr2OUdiSlC 3i7Gsd5ebfkbof+l14anms0ppG+bGH7h5/lQZisinFXBEKaEc7HJuXkJ8kLV/ivQjTPI RbNG2P7vgohYR+djCErOz+k2JiEUsYUn4doqZAMP2Mj6W6avck/T5lwbGfKS7MQIAQWK Mq6DWjZkFHOm/ipUlrJqi3PorXQBh/RlLb1vNj3MT5MlwTieUFKAgSJQ+dMErCEaMSRv qfIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9KeyRkpDZVKgACFsR86ZLUtYw0/zMx2nBt8gsEy4VkY=; b=nfmUGcRjk4au4c9EMvOqjvOZamuiDOGzfn7/hiNxt0F4E4lQRI/Gd8l4uE4y3y4RPB Mu1z6t8CyMY3gpWYNYTW6AZRRb9sDtK+ArysRxrEdFonXgGLDH+/iyjYte2FzNNUxDCv +Gz+2MQCgL+k8vI9z939J78AkBbT6sqXPcyndHP+Tq4xmLRBmi+gRbwE7u/D0QNa8yiE t05/iZYpS//IPI6u2CwN1vm1HH+oQqsrUvh/b0gKvuqMFt82PJFHtqolaU/vfbdWywNT TpX8XXniMff3Vqbik8ZckOOcd5jrlY3t3iw5oLQAEwKeQJj1+FrdPmKt8qrQ/tn1Nmbz SOJw== X-Gm-Message-State: APjAAAXBZOhRQoFbLPmVSCHS+EeJMMHkaFbT2bg512YSTW6CVUH6JF20 MPa2VuIsKjfjuVjasEVfCueJ6wFgH7/IVJkdYlGerw== X-Received: by 2002:a05:6808:2:: with SMTP id u2mr16609433oic.24.1574516643786; Sat, 23 Nov 2019 05:44:03 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:384:0:0:0:0:0 with HTTP; Sat, 23 Nov 2019 05:44:02 -0800 (PST) In-Reply-To: <20191120205119.41cd5989@Phenom-II-x6.niklas.com> References: <20191120205119.41cd5989@Phenom-II-x6.niklas.com> From: Tom Psyborg Date: Sat, 23 Nov 2019 14:44:02 +0100 Message-ID: Subject: Re: [RFC] why do sensors break CPU scaling To: David Niklas Cc: Linux Kernel Mailing List Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 21/11/2019, David Niklas wrote: > On Wed, 20 Nov 2019 21:42:12 +0100 > Tom Psyborg wrote: >> Hi >> >> Recently I've needed to set lowest CPU scaling profile, running ubuntu >> 16.04.06 I used standard approach - echoing powersave to >> /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor. >> This did not work as the >> /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq kept returning >> max scaling freq. >> >> During testing of ubuntu 19.10 I've found that the above approach >> actually does work, but as long as there are no xsensors (or just >> sensors from cli) being run. >> cpuinfo_cur_freq in this case was returning variable values +- 1% of >> around 1.4GHz. >> As soon as I issue sensors command cpuinfo_cur_freq jumps to 3.5GHz >> for a fraction of second and returns back to 1.4GHz afterwards. If >> running xsensors it keeps bouncing between 1.4 and 3.5GHz all the >> time. >> >> Rebooted back to 16.04.6 and was able to set lowest CPU scaling freq >> as well, but issuing sensors command here once just breaks CPU scaling >> that now remains at about 3.5GHz. >> It can be set to lowest scaling freq again without rebooting but it >> needs to change scaling_governor for all cores to something else and >> then back to powersave. >> >> Why is this happening, shouldn't sensors command just read temp/fan >> values without writing to any of the CPU control registers? > > I don't know if the maintainers will notice your email, but I did. I > don't guarantee that they'll notice or help you, but this should assist > you in writing a proper question. > You need to include the output of uname -a on both ubuntu boxes. The > output of: > dpkg -l xsensors > dpkg -l lm-sensors this is on 16.04.6 whtw46ww4@I5576:~$ uname -a Linux I5576 4.15.0-51-generic #55~16.04.1-Ubuntu SMP Thu May 16 09:24:37 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux whtw46ww4@I5576:~$ dpkg -l xsensors Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================================-===========================-===========================-=============================================================================================== ii xsensors 0.70-3 amd64 hardware health information viewer whtw46ww4@I5576:~$ dpkg -l lm-sensors Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=============================================-===========================-===========================-=============================================================================================== ii lm-sensors 1:3.4.0-2 amd64 utilities to read temperature/voltage/fan sensors > > The information on which processor you own and the motherboard and > it's BIOS version just in case. > > This is just my understanding and it might be wrong, but the CPU is > probably accessed to do the request to the fan values and so it ramps up > expecting to have to deal with a more intense workload (which is exactly > what Ryzen and several newer Intel processors are supposed to do), and so > you're seeing expected behavior. I don't think that is the case here, since I can run any kind of more demanding app than xsensors is, even compile software with -j 5 (multithread) and CPU clocks don't exceed 1.40GHz. Only on xsensors launch CPU clocks are reset. Regards, Tom