linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dietmar Eggemann <dietmar.eggemann@arm.com>
To: Parth Shah <parth@linux.ibm.com>,
	Vincent Guittot <vincent.guittot@linaro.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	"open list:THERMAL" <linux-pm@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Patrick Bellasi <patrick.bellasi@matbug.net>,
	Valentin Schneider <valentin.schneider@arm.com>,
	Pavel Machek <pavel@ucw.cz>, Doug Smythies <dsmythies@telus.net>,
	Quentin Perret <qperret@qperret.net>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>
Subject: Re: [RFC v5 4/6] sched/fair: Tune task wake-up logic to pack small background tasks on fewer cores
Date: Thu, 10 Oct 2019 16:53:12 +0200	[thread overview]
Message-ID: <6a620fc4-daf9-dd02-7a81-3d9364bfe162@arm.com> (raw)
In-Reply-To: <0ee8052e-e7fb-83cb-bf70-3c4855ccca8e@linux.ibm.com>

On 09/10/2019 19:02, Parth Shah wrote:
> 
> 
> On 10/9/19 7:56 PM, Dietmar Eggemann wrote:
>> On 09/10/2019 10:57, Parth Shah wrote:
>>
>> [...]
>>
>>>> On 07/10/2019 18:53, Parth Shah wrote:
>>>>>
>>>>>
>>>>> On 10/7/19 5:49 PM, Vincent Guittot wrote:
>>>>>> On Mon, 7 Oct 2019 at 10:31, Parth Shah <parth@linux.ibm.com> wrote:

[...]

> ok. so does that mean TurboSched can still do some good in such systems as
> well ?
> I mean save energy even when rd->overutilized==1 by not waking user
> classified bg tasks on idle core.

I wouldn't say it is impossible but how likely would it be?

The Android runtime already classifies its tasks into groups such as
background, foreground, top-app, etc. It uses existing infrastructure
like cpusets, taskgroups, util_clamp (or its out-of-tree predecessor
schedtune) as well as EAS/Energy Model on asymmetric CPU capacity
systems to map them (differently) onto the CPU topology to achieve the
best possible performance/energy consumption trade-off.

Moreover, Google and Arm are keen getting the concept of 'latency nice'
upstream so we can map Android Common Kernel's 'prefer idle' feature
into the mainline energy-aware wu path.

So I'm afraid the question whether TurboSched could make sense on an
Android system can only be answered by people responsible for future
Android runtime architecture.

  reply	other threads:[~2019-10-10 14:53 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-07  8:30 [RFC v5 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations Parth Shah
2019-10-07  8:30 ` [RFC v5 1/6] sched/core: Add manual background task classification using sched_setattr syscall Parth Shah
2019-10-07  8:30 ` [RFC v5 2/6] sched: Introduce switch to enable TurboSched for task packing Parth Shah
2019-10-07  8:30 ` [RFC v5 3/6] sched/core: Update turbo_sched count only when required Parth Shah
2019-10-07  8:30 ` [RFC v5 4/6] sched/fair: Tune task wake-up logic to pack small background tasks on fewer cores Parth Shah
2019-10-07 12:19   ` Vincent Guittot
2019-10-07 16:53     ` Parth Shah
2019-10-08 16:20       ` Vincent Guittot
2019-10-09  8:46         ` Parth Shah
2019-10-08 16:52       ` Dietmar Eggemann
2019-10-09  8:57         ` Parth Shah
2019-10-09 14:26           ` Dietmar Eggemann
2019-10-09 17:02             ` Parth Shah
2019-10-10 14:53               ` Dietmar Eggemann [this message]
2019-10-07  8:30 ` [RFC v5 5/6] sched/fair: Provide arch hook to find domain for non idle core search scan Parth Shah
2019-10-07  8:30 ` [RFC v5 6/6] powerpc: Set turbo domain to NUMA node for task packing Parth Shah
     [not found] ` <20191008132842.6612-1-hdanton@sina.com>
2019-10-09  9:22   ` [RFC v5 4/6] sched/fair: Tune task wake-up logic to pack small background tasks on fewer cores Parth Shah
2019-10-09 11:34     ` Vincent Guittot
2019-10-09 16:55       ` Parth Shah

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=6a620fc4-daf9-dd02-7a81-3d9364bfe162@arm.com \
    --to=dietmar.eggemann@arm.com \
    --cc=daniel.lezcano@linaro.org \
    --cc=dsmythies@telus.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=parth@linux.ibm.com \
    --cc=patrick.bellasi@matbug.net \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=qperret@qperret.net \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tim.c.chen@linux.intel.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.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).