linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: Borislav Petkov <bp@suse.de>, "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
	linux-edac@vger.kernel.org, X86 ML <x86@kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	bberg@redhat.com, Tony Luck <tony.luck@intel.com>
Subject: Re: [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether
Date: Tue, 14 Apr 2020 13:49:21 -0700	[thread overview]
Message-ID: <81359df9983fb70bd40ddb3be9090e5521294529.camel@linux.intel.com> (raw)
In-Reply-To: <20200414202328.GK31763@zn.tnic>

On Tue, 2020-04-14 at 22:23 +0200, Borislav Petkov wrote:
> + Tony.
> 
> On Tue, Apr 14, 2020 at 01:41:08PM -0600, Jason A. Donenfeld wrote:
> > Generally it is desirable, and extremely common too. This thermal
> > code
> > -- which mostly functions to print some messages into kmsg -- is
> > very
> > verbose. This is not something I want to compile into smaller
> > systems.
> > This is the reason why kconfig has options in the first place. I'm
> > not
> > sure yet-another boottime flag makes sense for this.
> 
> I don't mind making the already existing option selectable and
> leaving
> it default y, i.e., keeping the current situation by default. And
> people
> who want to disable it, can then do so.
> 
> I do mind to having yet another config option though. No thanks -
> they're already too many.
> 
> So it should be an all or nothing thing.
> 
> Poking quickly at that and
> drivers/thermal/intel/x86_pkg_temp_thermal.c,
> all those things do is report trip points. therm_throt reports how
> long
> the hw throttled due to hitting a trip point, etc.
> 
> IINM, of course so please correct me if I'm missing anything.
> 
> But if not and this all is only for reporting and doesn't have any
> detrimental effects on the hardware when missing from the system,
> then I
> guess we could make CONFIG_X86_THERMAL_VECTOR user-selectable.

We can make user selectable

These drivers are used for reporting only.
User space can select a trip temperature via x86_pkg_temp and get
notification via uevent to start additional cooling system (additional
fans, liquid coooling etc), so that processor don't have to go self
throttling mode. Self throttling depending on processor series and
firmware can be very aggressive.
In client systems thermald will set a temperature and starts power
control once it reaches passive temperature limit. But it can function
without x86_pkg_temp also, so even if user disables thermal reporting
it can still function.
 
Thanks,
Srinivas


> 
> Thx.
> 


  reply	other threads:[~2020-04-14 20:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-07  6:33 [PATCH 1/3] x86/mce/therm_throt: remove unused platform_thermal_notify function pointer Jason A. Donenfeld
2020-04-07  6:33 ` [PATCH 2/3] x86/mce/therm_throt: allow disabling verbose logging Jason A. Donenfeld
2020-04-07  6:33 ` [PATCH 3/3] x86/mce/therm_throt: allow disabling the thermal vector altogether Jason A. Donenfeld
2020-04-14  3:38   ` Srinivas Pandruvada
2020-04-14  4:21     ` Jason A. Donenfeld
2020-04-14 14:45       ` Srinivas Pandruvada
2020-04-14 19:41         ` Jason A. Donenfeld
2020-04-14 19:58           ` Srinivas Pandruvada
2020-04-14 20:09             ` Jason A. Donenfeld
2020-04-14 20:23           ` Borislav Petkov
2020-04-14 20:49             ` Srinivas Pandruvada [this message]
2020-04-14 21:07               ` Jason A. Donenfeld
2020-04-14 21:51                 ` Srinivas Pandruvada
2020-04-14 21:40   ` Peter Zijlstra
2020-04-14 21:44     ` Srinivas Pandruvada
2020-04-13 21:09 ` [PATCH 1/3] x86/mce/therm_throt: remove unused platform_thermal_notify function pointer Jason A. Donenfeld
2020-04-14  3:55 ` Srinivas Pandruvada
2020-04-14  4:21   ` Jason A. Donenfeld
2020-04-14 14:49     ` Srinivas Pandruvada

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=81359df9983fb70bd40ddb3be9090e5521294529.camel@linux.intel.com \
    --to=srinivas.pandruvada@linux.intel.com \
    --cc=Jason@zx2c4.com \
    --cc=arnd@arndb.de \
    --cc=bberg@redhat.com \
    --cc=bp@suse.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).