LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Joel Fernandes <joel@joelfernandes.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Juri Lelli <juri.lelli@redhat.com>,
	Viresh Kumar <viresh.kumar@linaro.org>,
	Claudio Scordino <claudio@evidence.eu.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Patrick Bellasi <patrick.bellasi@arm.com>,
	Luca Abeni <luca.abeni@santannapisa.it>,
	Joel Fernandes <joelaf@google.com>,
	Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests
Date: Wed, 9 May 2018 10:41:48 +0200	[thread overview]
Message-ID: <CAJZ5v0j8RgzYFAc8Fj5D_or8v0rG_h2DGQQKqyCLKbN2BE1jUg@mail.gmail.com> (raw)
In-Reply-To: <20180509082259.GB76874@joelaf.mtv.corp.google.com>

On Wed, May 9, 2018 at 10:22 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
> On Wed, May 09, 2018 at 10:05:09AM +0200, Rafael J. Wysocki wrote:
>> On Wed, May 9, 2018 at 9:01 AM, Joel Fernandes <joel@joelfernandes.org> wrote:
>> > On Wed, May 09, 2018 at 12:24:49PM +0530, Viresh Kumar wrote:
>> >> On 09-05-18, 08:45, Juri Lelli wrote:
>> >> > On 08/05/18 21:54, Joel Fernandes wrote:
>> >> > Isn't this potentially introducing unneeded irq pressure (and doing the
>> >> > whole wakeup the kthread thing), while the already active kthread could
>> >> > simply handle multiple back-to-back requests before going to sleep?
>> >>
>> >> And then we may need more instances of the work item and need to store
>> >> a different value of next_freq with each work item, as we can't use
>> >> the common one anymore as there would be races around accessing it ?
>> >
>> > Exactly. I think it also doesn't make sense to over write an already
>> > committed request either so better to store them separate (?). After the
>> > "commit", that previous request is done..
>>
>> Why is it?
>>
>> In the non-fast-switch case the "commit" only means queuing up an
>> irq_work.  Which BTW is one of the reasons for having work_in_progress
>> even if your kthread can handle multiple work items in one go.
>
> Ok I agree. I just thought there was something funky with the meaning of
> commit from a cpufreq perspective.
>
> In the last diff I just sent out, I actually keep work_in_progress and
> consider its meaning to be what you're saying (has the kthread been kicked)
> and lets such "overwriting" of the next frequency to be made possible. Also
> with that we would be servicing just the latest request even if there were
> multiple ones made.

My understanding of this is that when the kthread actually starts
changing the frequency, it can't really roll back (at least not in
general), but there may be multiple following requests while the
frequency is being changed.  In that case the most recent of the new
requests is the only one that matters.  So IMO the kthread should make
a local copy of the most recent request to start with, process it and
let the irq_work update the most recent request data as new requests
come in.  When done with the previous frequency change, the kthread
can make a local copy of the most recent request again and so on.

This should work, because there is only one irq_work updating the most
recent request data.

  reply	other threads:[~2018-05-09  8:41 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-07 14:43 Claudio Scordino
2018-05-08  6:54 ` Viresh Kumar
2018-05-08 12:32   ` Claudio Scordino
2018-05-08 20:40     ` Rafael J. Wysocki
2018-05-09  4:54   ` Joel Fernandes
2018-05-09  6:45     ` Juri Lelli
2018-05-09  6:54       ` Viresh Kumar
2018-05-09  7:01         ` Joel Fernandes
2018-05-09  8:05           ` Rafael J. Wysocki
2018-05-09  8:22             ` Joel Fernandes
2018-05-09  8:41               ` Rafael J. Wysocki [this message]
2018-05-09  8:23             ` Juri Lelli
2018-05-09  8:25               ` Rafael J. Wysocki
2018-05-09  8:41                 ` Juri Lelli
2018-05-09  6:55       ` Joel Fernandes
2018-05-09  8:06       ` Joel Fernandes
2018-05-09  8:30         ` Rafael J. Wysocki
2018-05-09  8:40           ` Viresh Kumar
2018-05-09  9:02             ` Joel Fernandes
2018-05-09  9:28               ` Viresh Kumar
2018-05-09 10:34                 ` Joel Fernandes
2018-05-09  8:51           ` Joel Fernandes
2018-05-09  9:06             ` Rafael J. Wysocki
2018-05-09  9:39               ` Joel Fernandes
2018-05-09  9:48                 ` Rafael J. Wysocki

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=CAJZ5v0j8RgzYFAc8Fj5D_or8v0rG_h2DGQQKqyCLKbN2BE1jUg@mail.gmail.com \
    --to=rafael@kernel.org \
    --cc=claudio@evidence.eu.com \
    --cc=joel@joelfernandes.org \
    --cc=joelaf@google.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=luca.abeni@santannapisa.it \
    --cc=mingo@redhat.com \
    --cc=patrick.bellasi@arm.com \
    --cc=peterz@infradead.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=viresh.kumar@linaro.org \
    --subject='Re: [RFC PATCH] sched/cpufreq/schedutil: handling urgent frequency requests' \
    /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

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).