LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Parth Shah <parth@linux.ibm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	mingo@redhat.com, dietmar.eggemann@arm.com, dsmythies@telus.net
Subject: Re: [RFCv2 6/6] sched/fair: Bound non idle core search by DIE domain
Date: Thu, 16 May 2019 21:56:08 +0530	[thread overview]
Message-ID: <6c7956f0-3ef0-ac6d-d950-b0ed8358b0db@linux.ibm.com> (raw)
In-Reply-To: <20190515164414.GY2589@hirez.programming.kicks-ass.net>



On 5/15/19 10:14 PM, Peter Zijlstra wrote:
> On Wed, May 15, 2019 at 07:23:22PM +0530, Parth Shah wrote:
>> This patch specifies the sched domain to search for a non idle core.
>>
>> The select_non_idle_core searches for the non idle cores across whole
>> system. But in the systems with multiple NUMA domains, the Turbo frequency
>> can be sustained within the NUMA domain without being affected from other
>> NUMA.
>>
>> This patch provides an architecture specific implementation for defining
>> the turbo domain to make searching of the core to be bound within the NUMA.
> 
> NAK, this is insane. You don't need arch hooks to find the numa domain.
> 

The aim here is to limit searching for non-idle cores inside a NUMA node
(or DIE sched-domain), because some systems can sustain Turbo frequency by task
packing inside of a NUMA node. Hence turbo domain for them should be DIE.

Since not all systems have DIE domain, adding arch hooks can allow each arch to
override their turbo domain within which to allow task packing.

Thanks


  reply	other threads:[~2019-05-16 16:26 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-15 13:53 [RFCv2 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations 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 [this message]
2019-05-15 16:48 ` [RFCv2 0/6] TurboSched: A scheduler for sustaining Turbo Frequencies for longer durations Peter Zijlstra
2019-05-16 16:05   ` 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=6c7956f0-3ef0-ac6d-d950-b0ed8358b0db@linux.ibm.com \
    --to=parth@linux.ibm.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=dsmythies@telus.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.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).