linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: psodagud@codeaurora.org
To: Steven Rostedt <rostedt@goodmis.org>
Cc: peterz@infradead.org, tglx@linutronix.de, qais.yousef@arm.com,
	mingo@kernel.org, cai@lca.pw, tyhicks@canonical.com,
	arnd@arndb.de, rameezmustafa@codeaurora.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] measure latency of cpu hotplug path
Date: Sun, 27 Sep 2020 19:41:45 -0700	[thread overview]
Message-ID: <75eca1a41e49a199d7aa72be8c5221b3@codeaurora.org> (raw)
In-Reply-To: <20200924105823.0e11f2e4@oasis.local.home>

On 2020-09-24 07:58, Steven Rostedt wrote:
> On Thu, 24 Sep 2020 10:34:14 +0200
> peterz@infradead.org wrote:
> 
>> On Wed, Sep 23, 2020 at 04:37:44PM -0700, Prasad Sodagudi wrote:
>> > There are all changes related to cpu hotplug path and would like to seek
>> > upstream review. These are all patches in Qualcomm downstream kernel
>> > for a quite long time. First patch sets the rt prioity to hotplug
>> > task and second patch adds cpuhp trace events.
>> >
>> > 1) cpu-hotplug: Always use real time scheduling when hotplugging a CPU
>> > 2) cpu/hotplug: Add cpuhp_latency trace event
>> 
>> Why? Hotplug is a known super slow path. If you care about hotplug
>> latency you're doing it wrong.
Hi Peter,

[PATCH 1/2] cpu/hotplug: Add cpuhp_latency trace event -
1)	Tracing of the cpuhp operation is important to find whether upstream 
changes or out of tree modules(or firmware changes) caused latency 
regression or not.
2)	Secondary cpus are hotplug out during the device suspend and hotplug 
in during the resume.
3)	firmware(psci calls handling from firmware) changes impact need to be 
tested right?
4)	cpu hotplug framework(CPUHP_AP_ONLINE_DYN) dynamic callbacks may 
impact the hotplug latency.


[PATCH 2/2] cpu-hotplug: Always use real time scheduling when  
hotplugging a CPU –

CPU hotplug operation is stressed and while stress testing with full 
load on the system following problem is observed.
CPU hotplug operations take place in preemptible context. This leaves 
the hotplugging thread at the mercy of overall system load and CPU
availability. If the hotplugging thread does not get an opportunity to 
execute after it has already begun a hotplug operation, CPUs can
end up being stuck in a quasi online state. In the worst case a CPU can 
be stuck in a state where the migration thread is parked while
another task is executing and changing affinity in a loop. This 
combination can result in unbounded execution time for the running
task until the hot plugging thread gets the chance to run to complete 
the hotplug operation.

-Thanks, Prasad

> 
> I'd like to know the answer to Peter's question too. Why?
> 
> -- Steve

  reply	other threads:[~2020-09-28  2:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 23:37 [PATCH 0/2] measure latency of cpu hotplug path Prasad Sodagudi
2020-09-23 23:37 ` [PATCH 1/2] cpu/hotplug: Add cpuhp_latency trace event Prasad Sodagudi
2020-09-28 14:58   ` Thomas Gleixner
2020-09-23 23:37 ` [PATCH 2/2] cpu-hotplug: Always use real time scheduling when hotplugging a CPU Prasad Sodagudi
2020-09-24  8:34 ` [PATCH 0/2] measure latency of cpu hotplug path peterz
2020-09-24 14:58   ` Steven Rostedt
2020-09-28  2:41     ` psodagud [this message]
2020-09-28  7:40       ` Peter Zijlstra

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=75eca1a41e49a199d7aa72be8c5221b3@codeaurora.org \
    --to=psodagud@codeaurora.org \
    --cc=arnd@arndb.de \
    --cc=cai@lca.pw \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=rameezmustafa@codeaurora.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tyhicks@canonical.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 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).