All of lore.kernel.org
 help / color / mirror / Atom feed
From: Subhra Mazumdar <subhra.mazumdar@oracle.com>
To: Peter Zijlstra <peterz@infradead.org>, Parth Shah <parth@linux.ibm.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	vincent.guittot@linaro.org
Subject: Re: [RFC 0/2] Optimize the idle CPU search
Date: Tue, 9 Jul 2019 12:15:53 +0530	[thread overview]
Message-ID: <ebbe2d76-c8b5-e52f-897b-7bcbfe0d820a@oracle.com> (raw)
In-Reply-To: <20190708080836.GW3402@hirez.programming.kicks-ass.net>


On 7/8/19 1:38 PM, Peter Zijlstra wrote:
> On Mon, Jul 08, 2019 at 10:24:30AM +0530, Parth Shah wrote:
>> When searching for an idle_sibling, scheduler first iterates to search for
>> an idle core and then for an idle CPU. By maintaining the idle CPU mask
>> while iterating through idle cores, we can mark non-idle CPUs for which
>> idle CPU search would not have to iterate through again. This is especially
>> true in a moderately load system
>>
>> Optimize idle CPUs search by marking already found non idle CPUs during
>> idle core search. This reduces iteration count when searching for idle
>> CPUs, resulting in lower iteration count.
> Have you seen these patches:
>
>    https://lkml.kernel.org/r/20180530142236.667774973@infradead.org
>
> I've meant to get back to that, but never quite had the time :/
The most relevant bit of this was folding select_idle_core and
select_idle_cpu. But it may be good to keep them separate as workloads
which just want any idle cpu can find one and break early by disabling
the idle core search. And this can still work with latency-nice which can
moderate both idle core and idle cpu search.


  parent reply	other threads:[~2019-07-09  6:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-08  4:54 [RFC 0/2] Optimize the idle CPU search Parth Shah
2019-07-08  4:54 ` [RFC 1/2] sched/fair: Rename select_idle_mask to iterator_mask Parth Shah
2019-07-08  4:54 ` [RFC 2/2] sched/fair: Optimize the idle CPU search Parth Shah
2019-07-08  8:08 ` [RFC 0/2] " Peter Zijlstra
2019-07-08  9:09   ` Parth Shah
2019-07-09  6:45   ` Subhra Mazumdar [this message]
2019-07-09  0:08 ` Subhra Mazumdar
2019-07-09  5:38   ` Parth Shah
2019-07-09  6:48     ` Subhra Mazumdar

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=ebbe2d76-c8b5-e52f-897b-7bcbfe0d820a@oracle.com \
    --to=subhra.mazumdar@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=parth@linux.ibm.com \
    --cc=peterz@infradead.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.