LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Viresh Kumar <viresh.kumar@linaro.org>
To: Quentin Perret <quentin.perret@arm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
linux-pm@vger.kernel.org, Pavan Kondeti <pkondeti@codeaurora.org>,
"Rafael J . Wysocki" <rafael.j.wysocki@intel.com>,
Juri Lelli <juri.lelli@redhat.com>,
Joel Fernandes <joelaf@google.com>,
Patrick Bellasi <patrick.bellasi@arm.com>
Subject: Re: [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily"
Date: Tue, 8 May 2018 16:04:27 +0530 [thread overview]
Message-ID: <20180508103427.w2rq3vz3f66y4cxh@vireshk-i7> (raw)
In-Reply-To: <20180508100227.GB3752@e108498-lin.cambridge.arm.com>
On 08-05-18, 11:02, Quentin Perret wrote:
> The sugov kthreads are DL tasks so they're not impacted by EAS. But even
> if you take EAS out of the picture, those kthreads are assigned to a
> "random" CPU at boot time and stay there forever (because that's how DL
> works). Is this what we want ?
Okay, I didn't knew that DL threads don't migrate at all. I don't
think that's what we want then specially for big LITTLE platforms. But
for the rest, I don't know. Take example of Qcom krait. Each CPU has a
separate policy, why shouldn't we allow other CPUs to run the kthread?
> Looking at the commit you mention below it seems that you did the
> testing on the old hikey which has only one cpufreq policy. Did you try
> on other platforms as well ?
Yeah, the testing wasn't performance oriented but rather corner case
oriented and it made sense to allow other CPUs to go update the freq
for remote CPUs. And that's true for big LITTLE as well, the only
question here is which CPUs we want the thread to run on.
--
viresh
next prev parent reply other threads:[~2018-05-08 10:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-08 7:33 [PATCH] Revert "cpufreq: schedutil: Don't restrict kthread to related_cpus unnecessarily" Dietmar Eggemann
2018-05-08 8:22 ` Viresh Kumar
2018-05-08 9:09 ` Dietmar Eggemann
2018-05-08 9:42 ` Quentin Perret
2018-05-13 5:19 ` Joel Fernandes
2018-05-17 19:10 ` Saravana Kannan
2018-05-17 19:13 ` Joel Fernandes
2018-05-08 9:45 ` Viresh Kumar
2018-05-08 10:02 ` Quentin Perret
2018-05-08 10:34 ` Viresh Kumar [this message]
2018-05-08 11:00 ` Quentin Perret
2018-05-08 11:14 ` Viresh Kumar
2018-05-08 11:24 ` Quentin Perret
2018-05-08 12:20 ` Juri Lelli
2018-05-08 20:36 ` Rafael J. Wysocki
2018-05-09 4:55 ` Viresh Kumar
2018-05-08 10:36 ` Dietmar Eggemann
2018-05-08 10:53 ` Viresh Kumar
2018-05-08 12:17 ` Juri Lelli
2018-05-09 4:55 ` Viresh Kumar
2018-05-17 10:32 ` 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=20180508103427.w2rq3vz3f66y4cxh@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=dietmar.eggemann@arm.com \
--cc=joelaf@google.com \
--cc=juri.lelli@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=patrick.bellasi@arm.com \
--cc=peterz@infradead.org \
--cc=pkondeti@codeaurora.org \
--cc=quentin.perret@arm.com \
--cc=rafael.j.wysocki@intel.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).