linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vincent Guittot <vincent.guittot@linaro.org>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Valentin Schneider <valentin.schneider@arm.com>,
	Thara Gopinath <thara.gopinath@linaro.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: v5.7: new core kernel option missing help text
Date: Wed, 3 Jun 2020 22:22:38 +0200	[thread overview]
Message-ID: <CAKfTPtAweyV44Dqv1vXm83aLy2PhaWBUnxro-ct=KVhr4XWGwA@mail.gmail.com> (raw)
In-Reply-To: <20200603195853.GD1551@shell.armlinux.org.uk>

On Wed, 3 Jun 2020 at 21:59, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> On Wed, Jun 03, 2020 at 09:24:56PM +0200, Vincent Guittot wrote:
> > On Wed, 3 Jun 2020 at 20:45, Russell King - ARM Linux admin
> > <linux@armlinux.org.uk> wrote:
> > > It's a start.  I'm still wondering whether I should answer yes or no
> > > for the platforms I'm building for.
> > >
> > > So far, all I've found is:
> > >
> > > arch/arm/include/asm/topology.h:#define arch_scale_thermal_pressure topology_get_thermal_pressure
> > >
> > > which really doesn't tell me anything about this.  So I'm still in
> > > the dark.
> > >
> > > I guess topology_get_thermal_pressure is provided by something in
> > > drivers/ which will be conditional on some driver or something.
> >
> > You need cpufreq_cooling device to make it useful and only for SMP
> > I don't think that this should not be user configurable because even
> > with the description above, it is not easy to choose.
> > This should be set by the driver that implement the feature which is
> > only cpufreq cooling device for now it
>
> As I have CONFIG_CPU_FREQ_THERMAL=y in my config, I'm guessing (and it's
> only a guess) that I should say y to SCHED_THERMAL_PRESSURE ?

yes, you're right

>
> > > > +     help
> > > > +       This option allows the scheduler to be aware of CPU thermal throttling
> > > > +       (i.e. thermal pressure), providing arch_scale_thermal_pressure() is
> > > > +       implemented.
>
> Is this feature documented in terms of what it does?  Do I assume that
> as the thermal trip points start tripping, that has an influence on
> the scheduler?  Or is it the case that the scheduler is wanting to
> know when the cpu frequency changes?

When the thermal trip points start tripping, we take into account the
decrease of the compute capacity of the CU. This reduced capacity is
used instead of max capacity when we balance the tasks between CPUs.

A similar mechanism is used to account the time "stolen" by IRQ or
RT/DL tasks to CFS tasks

>
> Grepping for "thermal" in Documentation/scheduler brings up nothing.

John Mathew sent a patch to add documentation:
https://lkml.org/lkml/2020/5/14/290

>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up

  reply	other threads:[~2020-06-03 20:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-03 17:31 v5.7: new core kernel option missing help text Russell King - ARM Linux admin
2020-06-03 18:00 ` Valentin Schneider
2020-06-03 18:45   ` Russell King - ARM Linux admin
2020-06-03 19:24     ` Vincent Guittot
2020-06-03 19:58       ` Russell King - ARM Linux admin
2020-06-03 20:22         ` Vincent Guittot [this message]
2020-06-03 20:25         ` Valentin Schneider
2020-06-04  0:48           ` Thara Gopinath
2020-06-04  9:26             ` Valentin Schneider
2020-06-04  9:29               ` Russell King - ARM Linux admin
2020-06-04 10:56                 ` Valentin Schneider
     [not found]                   ` <CALD-y_zQms4YQup2MgAfNhWSu=ewkhossHma2TKqfTcOFaG=uA@mail.gmail.com>
2020-06-04 15:38                     ` Valentin Schneider
2020-06-04 22:22                       ` Thara Gopinath
2020-06-05  7:03                       ` Vincent Guittot
2020-06-05  9:46                         ` Valentin Schneider
2020-06-05  8:15                       ` Russell King - ARM Linux admin
2020-06-05 10:02                         ` Valentin Schneider

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='CAKfTPtAweyV44Dqv1vXm83aLy2PhaWBUnxro-ct=KVhr4XWGwA@mail.gmail.com' \
    --to=vincent.guittot@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=thara.gopinath@linaro.org \
    --cc=valentin.schneider@arm.com \
    /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).