All of lore.kernel.org
 help / color / mirror / Atom feed
From: Atish Patra <atish.patra@oracle.com>
To: Josef Bacik <josef@toxicpanda.com>, Mike Galbraith <efault@gmx.de>
Cc: Uladzislau Rezki <urezki@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Joel Fernandes <joelaf@google.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Brendan Jackman <brendan.jackman@arm.com>,
	Josef Bacik <jbacik@fb.com>, Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window.
Date: Thu, 23 Nov 2017 15:11:49 -0600	[thread overview]
Message-ID: <367a9ab5-58a9-95cd-ae51-ae02979c11d5@oracle.com> (raw)
In-Reply-To: <20171123160006.tik2loyzzlavf5ub@destiny>



On 2017/11/23 10:00 AM, Josef Bacik wrote:
> On Thu, Nov 23, 2017 at 02:13:01PM +0100, Mike Galbraith wrote:
>> On Thu, 2017-11-23 at 11:52 +0100, Uladzislau Rezki wrote:
>>> Hello, Atish, Peter, all.
>>>
>>> I have a question about if a task's nr_cpus_allowed is 1.
>>> In that scenario we do not call select_task_rq. Therefore
>>> even thought a task "p" is placed on idle CPU that CPU
>>> will not be marked as claimed for wake-up.
>>>
>>> What do you think about adding per_cpu(claim_wakeup, cpu) = 1;
>>> to select_task_rq() instead and possibly get rid of them from
>>> other places (increases a race window a bit)?
>> My thoughts on all of this is that we need less SIS, not more.  Rather
>> than trying so hard for the absolute lowest wakeup latency, which
>> induces throughput/efficiency robbing bouncing, I think we'd be better
>> of considering leaving an already llc affine task where it is if the
>> average cycle time is sufficiently low that it will likely hit the CPU
>> RSN.  Completely ignoring low utilization kernel threads would go a
>> long way to getting rid of bouncing userspace (which tends to have a
>> meaningful footprint), all over hell and creation.
>>
>> You could also periodically send mobile kthreads down the slow path to
>> try to keep them the hell away from partially busy CPUs, as well as
>> anything else that hasn't run for a while, to keep background cruft
>> from continually injecting itself into the middle of a cross core
>> cyber-sex.
>>
> And on this thanksgiving I'm thankful for Mike, and his entertaining early
> morning emails.
:) :).
> Josef

  parent reply	other threads:[~2017-11-23 21:12 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-31  5:27 [PATCH RFC 0/2] Fix race window during idle cpu selection Atish Patra
2017-10-31  5:27 ` [PATCH RFC 1/2] sched: Minimize the idle cpu selection race window Atish Patra
2017-10-31  8:20   ` Peter Zijlstra
2017-10-31  8:48     ` Mike Galbraith
2017-11-01  6:08       ` Atish Patra
2017-11-01  6:54         ` Mike Galbraith
2017-11-01  7:18           ` Mike Galbraith
2017-11-01 16:36             ` Atish Patra
2017-11-01 20:20               ` Mike Galbraith
2017-11-05  0:58     ` Joel Fernandes
2017-11-22  5:23       ` Atish Patra
2017-11-23 10:52         ` Uladzislau Rezki
2017-11-23 13:13           ` Mike Galbraith
2017-11-23 16:00             ` Josef Bacik
2017-11-23 17:40               ` Mike Galbraith
2017-11-23 21:11               ` Atish Patra [this message]
2017-11-24 10:26             ` Uladzislau Rezki
2017-11-24 18:46               ` Mike Galbraith
2017-11-26 20:58                 ` Mike Galbraith
2017-11-28  9:34                 ` Uladzislau Rezki
2017-11-28 10:49                   ` Mike Galbraith
2017-11-29 10:41                     ` Uladzislau Rezki
2017-11-29 18:15                       ` Mike Galbraith
2017-11-30 12:30                         ` Uladzislau Rezki
2017-10-31  5:27 ` [PATCH DEBUG 2/2] sched: Add a stat for " Atish Patra

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=367a9ab5-58a9-95cd-ae51-ae02979c11d5@oracle.com \
    --to=atish.patra@oracle.com \
    --cc=brendan.jackman@arm.com \
    --cc=efault@gmx.de \
    --cc=jbacik@fb.com \
    --cc=joelaf@google.com \
    --cc=josef@toxicpanda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=urezki@gmail.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 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.