LKML Archive on
help / color / mirror / Atom feed
From: Peter Zijlstra <>
To: Parth Shah <>
Subject: Re: [RFCv2 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations
Date: Wed, 15 May 2019 18:48:54 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, May 15, 2019 at 07:23:16PM +0530, Parth Shah wrote:
> Abstract
> ========
> The modern servers allows multiple cores to run at range of
> frequencies higher than rated range of frequencies. But the power budget
> of the system inhibits sustaining these higher frequencies for
> longer durations.
> However when certain cores are put to idle states, the power can be
> effectively channelled to other busy cores, allowing them to sustain
> the higher frequency.
> One way to achieve this is to pack tasks onto fewer cores keeping others idle,
> but it may lead to performance penalty for such tasks and sustaining higher
> frequencies proves to be of no benefit. But if one can identify unimportant low
> utilization tasks which can be packed on the already active cores then waking up
> of new cores can be avoided. Such tasks are short and/or bursty "jitter tasks"
> and waking up new core is expensive for such case.
> Current CFS algorithm in kernel scheduler is performance oriented and hence
> tries to assign any idle CPU first for the waking up of new tasks. This policy
> is perfect for major categories of the workload, but for jitter tasks, one
> can save energy by packing it onto active cores and allow other cores to run at
> higher frequencies.
> These patch-set tunes the task wake up logic in scheduler to pack exclusively
> classified jitter tasks onto busy cores. The work involves the use of additional
> attributes inside "cpu" cgroup controller to manually classify tasks as jitter. 

Why does this make sense? Don't these higher freq bins burn power like
stupid? That is, it makes sense to use turbo-bins for single threaded
workloads that are CPU-bound and need performance.

But why pack a bunch of 'crap' tasks onto a core and give it turbo;
that's just burning power without getting anything back for it.

  parent reply	other threads:[~2019-05-15 16:49 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 13:53 Parth Shah
2019-05-15 13:53 ` [RFCv2 1/6] sched/core: Add manual jitter classification from cgroup interface Parth Shah
2019-05-15 16:29   ` Peter Zijlstra
2019-05-16 16:12     ` Parth Shah
2019-05-15 13:53 ` [RFCv2 2/6] sched: Introduce switch to enable TurboSched mode Parth Shah
2019-05-15 16:30   ` Peter Zijlstra
2019-05-16 16:15     ` Parth Shah
2019-05-15 13:53 ` [RFCv2 3/6] sched/core: Update turbo_sched count only when required Parth Shah
2019-05-15 16:31   ` Peter Zijlstra
2019-05-15 13:53 ` [RFCv2 4/6] sched/fair: Define core capacity to limit task packing Parth Shah
2019-05-15 16:37   ` Peter Zijlstra
2019-05-15 13:53 ` [RFCv2 5/6] sched/fair: Tune task wake-up logic to pack jitter tasks Parth Shah
2019-05-15 16:43   ` Peter Zijlstra
2019-05-15 13:53 ` [RFCv2 6/6] sched/fair: Bound non idle core search by DIE domain Parth Shah
2019-05-15 16:44   ` Peter Zijlstra
2019-05-16 16:26     ` Parth Shah
2019-05-15 16:48 ` Peter Zijlstra [this message]
2019-05-16 16:05   ` [RFCv2 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations 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:

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

  git send-email \ \ \ \ \ \ \ \ \
    --subject='Re: [RFCv2 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations' \

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